[TYPO3-ect] The Big Plan

[Elmar Hinz]

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.

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.