[TYPO3-extbase-kickstarter] Roundtrip concept for the kickstarter

[Nico de Haen]

Hi,

I would like to get some feedback concerning the roundtrip concept of
the kickstarter. It should be possible to extend models (and
controllers, repositories) even if they were modified before, without
loosing the modifications. I think that leads to changes in our Domain.

We have 2 different perspectives on the kickstarter then: the
perspective of a software developer who is aware of the classes, methods
and properties behind the objects and the perspective of a non-developer
who only knows about models as shown in the GUI. We can provide a
specific panel to the developer to show him for example method names,
property types etc.

To incorporate user modified content we have to parse the class file and
build a structured and semantic object representing the class (and the
class file). One big advantage of "knowing" what's in a class would be
that we can import models from other formats, merge them into existing
classes and apply restrictions (if we want)

So I added some models to the domain: a model representing a "class" in
the context of software developement, a model representing a method and
so on. The wording becomes a bit tricky now: We have a class
representing a "real world" class which is designed to represent a real
world object in any other domain...

Currently we have:

1. Tx_Extbase_Reflection_ClassReflection (extending the php reflection
class)

2. Tx_Extbase_Reflection_ClassSchema with persistence-specific
properties like "getUUIDPropertyName" etc.

3. Tx_ExtbaseKickstarter_Domain_Model_DomainObject, which is not a class
representation, but an object representation with extbase- specific
properties like "getDatabaseTableName" or "getDomainRepositoryClassName"

The Reflection class is php-specific and needs a classname of an
existing php class in the constructor, so it can't be used for importing
models from other sources. Besides that, the methods and properties are
"read-only" and no methods can be added.

The classSchema is obviously only meant to represent a model, not a
controller class or a repository class etc.
(all of them have no inherent idea of persistence for example). It would
be good if it would inherit from a more generic class then we could
extend that in different subclasses, but it's a class from FLOW3...

In the Domain of an extension editor a "Class" model needs a property
like "isModifiedByDeveloper" or "getModifiedMethods" and a "Method"
model needs a method like "getRawMethodBody" etc.

I implemented a prototype as a proof of concept (in branch
extension_editing) with 4 new model objects and an import utility class
that can parse a php file and build a class schema from it. It doesn't
write files right now, but builds an object containing all information
that was found in the file (including additional comments, includes
etc.). Have a look at the unit tests, the import is running in debug
mode right now.

Nico