[TYPO3-ect] MVC Project

[Elmar Hinz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

Ernesto Baschny [cron IT] schrieb:

> I think the validation and other processing from a view is handled by
> the controller. This controller should: check validity of input, do its
> processing and decide which is the next "view" to show.
> 
> TCAforms (view) gets information using TCAobjects (model). The form is
> send to TCAprocess (controller) to process and choose the next "view" to
> display.
> 

All of this are objects. How about TCAview, TCAmodel and TCAcontroller as names?
(I personally prefer camel style: tcaView).

> We almost already have such a thing in place for example:
> 
> typo3/alt_doc.php for editing a record. It defines the view and the
> controller, which should just be made two separate classes. Also the
> controller shouldn't just re-display the view: It should REDIRECT (with
> "Location"-Header) to a new view, which is a common way of handling the
> problem of "double-posting" of views in web-based applications. The TCA

Here we are amidst of the discussion how MVC should interact. There are
different concepts possible. How do we find the best way?

REDIRECT (with "Location"-Header) is one seasoned answer, but not the only one.
If the controller want's to influence settings of the new view, it would need to
send a lot of parameters together with the new Location or handle them through
the session. I wounder how backward compatible this solution is for TYPO3.

VALIDATION should be done on different levels. On the model level, on the
controller/view level and even with JavaScript in the client. It is an idea to
handle all this back to the model. But if we take the genration of JavaScript as
example, it is only one of many possible FE-script-languages (in theory). To
keep the kind of view really plugable this validation scripts can't be prepared
in the model. They belong to the view.

CONTROLLER: The classical controller catches the input from the keyboard or the
parameters from the request directly. This way the controller is dependent from
the kind of view (Gui, Website, etc.). I think the controlle shouldn't be
dependent from the view. The same workflow controller should work with a GUI or
with a website or with a PDF form or anything else. I think that the view itself
should catch the input and handle it to the controller through a defined interface.

It is a wide field. We need a structured discussion. We need coordination with
the core team.

I think we should compare and discuss the best know concepts first. The apache
software foundation (PHP is relatet as Sister Project) has collected a lot of
experiences here. To throw in some keywords: Struts, Avalon, Cocoon, Lenya, ...
Inversion of Control, ..., ActiveRecord, MonoRail, ....

We could start a collection of concepts in form of URLs and schemas like this:

http://www.castleproject.org/images/0/0f/Castle-stack.png

We could also ask some of the experienced developers of this projects for
concept proposals for TYPO3.


Do you have proposals for a flightplan?


Regards

Elmar




























> is just the configuration glue that holds all things together, so I

It's not a glue. It's anly an array with configurations.

> don't think there is a problem of having model, view and controller
> specific items in there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6KS6O976RNoy/18RAo9uAJ40wkZvgfFHqct0pyWg849jqW0cNQCeLGzu
gGCSGAUfKHHSXY0ZynHtgB8=
=x32k
-----END PGP SIGNATURE-----