Hello everybody, Hard times ==========
Currently, it's *very* hard to maintain an eZ Components app using around a hundred of models with constant updates, because you have to repeat yourself: - edit the database schema file, - edit the persistent object definitions, - edit the class code, - edit the form, - edit the controllers, - synchronize the database (one-liner). A few helpers are provided: - schema to persistent object definitions converter: which looses relations. - class generator: which creates a minimal class with public properties. Problem: My clients are, in majority, outstanding poeple that are very Human, and hard workers. I am very concerned by their success, which i assume is the same for eZ Systems. I don't want to charge a day of work to add/remove/change a field in the model layer (i even already charged for 2 days, to update all my fixtures). dzFramework =========== This is the reason why I'm currently developping a port of Django Python framework to eZ Components, as a temporary solution: until ezp5 framework. This gives a couple of relevent arguments about PersistentObject and MvcTools. Sources: svn://devangels.org/djez Please bear with the source and BDD, i started Monday. PersistentObject: DRY ===================== It is possible to make a flexible application, which involves the following tasks when updating the model layer: - edit the class/persistent object definition, - synchronize everything (one-liner). I don't see any cons for this, only pros: simple and fast, which results in: flexible. To satisfy the definition needs of both DatabaseSchema and PersistentObject, each class property should have the following values (DS=DatabaseSchema, PO=PersistentObject): - propertyName (string): the name of the class property, used in states as well, (PO) - columnName (string): the name of the column, used in DS and PO, - isIdProperty (bool): true if the property is the model's table id property, used in DS and PO, - maxLength* (int): maximal length of the value, used in DS, - null* (bool): true if the property accepts null values, used in DS, - default* (mixed): default value of the property, used in DS, - unsigned* (bool): true if the field accepts negative values, used in DS, - dbType** (const): type of the database field for DS, - poType** (const): type of the persistent object property, - primaryKey (bool): true if the field is a primary key, used in DS, - indexKey (bool): true if the field should be indexed, used in DS, * Options with this annotation would make sense to use in a default ezcPersistentPropertyConverter, which would be decorable/overloadable. ** Although we should assume that dbType and poType are the same, we should still allow the user to overload this assumption. What the class should know: - the table name, - the class name, - the relations, if not defined *within* the properties, which would make the application more flexible imho. Of course, we do want to set relevant defaults, but allow their overloading (set your value to ezcPersistentObjectProperty::$columnName after instanciation of the property for example). The point: specify all at once, and be able to generate the DS and PO def. In my opininion, these properties should be set once, somewhere either in: - the database schema, although that would be not be a good idea, - the persistent object definition itself, - the persistent object class. How flexible are relations? --------------------------- To define a simple relation, you currently have to: - create the FK property, - create the relation, - create the map. This is not based on assumptions at all. In the section "Defining a simple relation" of the tutorial, this requires 15 lines of code. Why? Because it's very flexible and configurable *but* not based on assumptions. For example, in my Django port, it's possible to create special properties very easely, for example: define a "simple relation" by adding a "ForeignKey" property. It's a one-liner. Just based on assumptions, the only argument that my FK field take is the name of the related class, and array $options = array(), which allows to overload any assumption. MvcTools tiein ============== In my framework, there are other properties and methods to overload, like $widget or alterPoDef( $def ) ... but that's not required until the MvcTools tiein, which will probably not see the light very soon, but will be "teh best". This is why i suggest to make another component, allowing to specify fields with loads of assumptions, usable to generate: - the schema, - the podef, - the form and controller, - the admin-site. What do we want to touch, what don't we want to touch? ------------------------------------------------------ I want to be able to touch my persistent classes, and not have to re-generate it which would loose my methods. However, my class can be parsed to generate a DbSchema or a PersistentObject definition, because i don't want to touch it anymore (remember: i defined everything in the class). Do we want scaffolding? ----------------------- We don't want scaffolding, scaffolding makes your application unflexible and unmaintainable because it's based on generating hard-code, which is the most irrelevent idea imho. Although it does make sense to scaffold the PO def and the DS def for caching purposes, we definitively want the form/controller and admin-site to be generated on the fly: based on 100% overloadable assumptions (not like Django, more like my port). Conclusion ========== I am convinced that this is the path to making a really flexible model layer and application. I'm still a newbie, doing OO since a year only, so i'm likely to make mistakes and be wrong, if you think it's possible to make a flexible application without adding this extra layer to DB/DS/PO, please share your tips! (The other thing my framework does, is magicall admin-site generation, has it's own server written in php (./manage.php runserver), or even ./manage.php syncdb, allows to overload any route, view, template, command like syncdb ... but it's pretty young: i started Monday, the plan is to get it running fast (today), then decouple classes while doing real TDD instead of BDD, then document). eZ Publish 5 ============ Do we want a web-interface to editing the model layer? ------------------------------------------------------ It's been years since developpers are using eZ Publish, do they need a web-interface that is not as flexible as being directly editing the model layer code? It's true that it's cool for a newbie to be able to developp his application by cliquing instead of coding, but that has no business-value for me, how much is it for eZ Systems? I am not saying that it would be a waste of time, i'm convinced that it's very cool to allow making a model layer without any programming knowledge! (though you might need to read the eZP basics book). My point is that it's possible to get some business value back from eZC and eZ partners without it, which means: much sooner. That's my consultant point-of-view, i can be wrong, there can be better for eZ, i'm still a newb as a consultant as well ;) Thanks ====== Thanks Kore Nordmann, Tobias Schlitt and Derick Rethans for pushing me to abort my Django dev. to port it to eZC, helping me all the time, showing me the path, etc etc ... You're awsome! Regards, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
