[TYPO3-ect] The Big Plan

[Mario Matzulla]

Hi Elmar, hi list,
Elmar Hinz schrieb:
> Hello,
> 
> as Christopher has asked for it, here comes the first part of "The big
> Plan". The first part contains an intro and 3 questions. The
> I publish it, so that it can be discussed.
> 
> The next parts will contain my proposals to answer this questions. The
> answer to the 3rd question is an internal question of the forms team.
> 
> I have registerd the key "form" for it. We will have a set of pretty short
> keys for the coordinated extensions: lib, div, forms, cal, articles, ...
> 
> I count cal into this. I think we can make cal a valuable example for the
> usage of lib + div + forms as soon as they are stable enough.

You can count cal into this!!! :)

Regards,
Mario
> 
> Regards
> 
> Elmar
> 
> 
> 
> 
> 
> The Big Plan of ECT (TM)
> 
> or
> 
> How formslib and MVC are related
> 
> 
> Introduction
> ============
> 
> When I started with object orientated web programming I played a little
> with the idea of general dataset objects. The idea is simple. In the
> mayority of cases each form we edit in the webpage responses exactly to one
> dataset in of the underlieing database. So why not making it one object
> that does it all? Inserting, updating, selecting, deleting, displaying and
> forms generation all with one object. If I build this object in a generic
> way, that means I make it configurable, I only need to programme it once.
> You got the idea?
> 
> I still can go a step further. In many cases the configuration could be
> guessed directly from the type of the database fields. I only need to
> finetune the forms configuration. Similar concepts of rapid prototyping
> have become popular with ruby on rails within the last years.
> 
> Such monolithic idea of one generic object can work in practice, but has
> disadvantages:
> 
> - The class of an almighty object is quickly getting big and confusing.
> - I need to integrate all kind of checkings and evaluations.
> - Forms are not the only source of our data.  Data income can also origin
> in from parsed emails, newsfeeds, daemons, ...
> - The web is not the only target of database data ....
> 
> After some experiences with this, you will understand that it is not the
> best idea to combine forms and queries into the same object. They have
> different functionality, they should be separated. At least at this point I
> understood the advantage and principle of the model view controller (MVC)
> paradigma.
> 
> You also will discover that a single general object for view or model is
> still unhandy with all those different types of fields. You better do it
> with libraries of objects. Different objects but with common inherited
> interfaces.
> 
> While you are separting different libraries for queries and forms the
> concepts of object generation from configuration is still useful. Jeff
> Segars and Michael Scharkow have proposed "tcaObjects" for the queries,
> where the configuration is taken from the TCA. TYPO3 TCA is already
> configured within the BE. We just need to reuse it. The forms can retrieve
> parts if their configuration from TCA, but it needs additional finetuning.
> 
> 
> Important questions
> ===================
> 
> Separation of queries and forms raises a few new questions:
> 
> 1.) How to coordinate the collaboration of forms and queries?
>     ---------------------------------------------------------
> 
>     A part of the answer is the controller.
> 
> 
> 2.) How to exchange the data between view and model without a lot of
> coding?
> ------------------------------------------------------------------------
> 
>   This is an important question, because one advantage of the monolithic
> solution is, that you do not need to program this type of exchange. MVC
> should keep this disadvantage is small as possible.
> 
>   One solution is to use a central php 5.0 interface frameworki: SPL -- the
> Simple PHP Library. It makes it this exchange surprisingly simple.
> 
> 
>  3.) How to use the ideas of rapid prototyping for building forms?
>      -------------------------------------------------------------
> 
>   In rails the configuration of rapid protoping is retrieved from the DB
> fields. In TYPO3 we invert this procedure. We build the configuration (TCA)
> before the DB tables are generated. We usually do this with the
> kickstarter. We can understand the kickstarter as an rapid prototyping wizard.
> 
>   However the TCA does not contain all configuration we need to generate
> the forms. We need to discuss the best solutions to fill this gap.
> 
>