[TYPO3-ect] lib/div 1.0 - it's time to say thank you

[Elmar HInz]

Hi Ernesto,

> 
> Is there a "show-off extension" that makes use of most of the classes
> from "lib" already?
> 

Here you find the entry point of all Information:

http://wiki.typo3.org/index.php/MVC_Framework

* apples is the minimilistic example without a real action in your sense.
* efaq is a full size example, also without a "real" action. 
* articles has an a submit form and so a "real" action.

> Some things made me wonder, but maybe I just didn't get it:
> 
> I think it is not clearly specified what an "action" is, as I use it
> differently. Where does your definition of "action" comes from? Is this
> well known in the MVC pattern? It seems from the code that an action can
> either return HTML to be displayed in the frontend or maybe do a
> redirect to another page. And every call to the plugin has an "action".
> 

I use it much in the way I have seen it in the Zend Framework. There the
"controller" calls a class and the "action" calls a function in the class
if I remember right. 

Let's compare Zend Framework. We don't need a "controller" parameter. That
is indirectly given by the page "id". For each page the plugin controllers
are defined by TS. But I always need a starting function inside the
controller wich I call "Action". That is always true. Every starting
function has the postfix "Action". Independent of the fact if there is a
"real" action or a simple static call. That is my basical design.

The action "printList"  calls  printListAction() etc.

For the majority of plugins without a "real" action as incomming GET or
POST parameter you can define the action by TS, wich gives you a lot of
flexibility to controll things by simple TS configuration. I have used
that a lot in my last commercial project: http://enob.info.

If you don't set an action at all, the function "defaultAction" is used by
default. This way you can work "without" actions for static calls by
giving them an own controller class each. But you still need to define the
defaultAction function as starting point inside each controller class.

> 
> 1) if there is an action to process (usually when the user submits a
> POST-form):
> 
> a) Create a controller object based on the parameters
> b) Call "processRequest" on the controller. This should do it's job
> (update the model)
> c) Controller will return information to the "plugin controller" about
> what to do next:
> - nextView -> just loads and display a new view
> - redirect -> if processing went OK, we *redirect* with new parameters

I know the *redirect* is very usefull after processing a form. I would
also recommend that as a standard. You certainly can use both alternatives
with the lib/div controller. You even can set a new action with the
redirect, to controll what happens next. Usually a page id is enough in
this case.

> 2) after processing any potential "action" (update-controllers), we
> just
> load the requested "view" (requested either by URL parameters, by
> TypoScript, Flexform or by the previous update-controller). The view
> will then make all computation behind the generation of such an output
> and potentially delegate the rendering to a templating engine. So the
> "view" for me is not just the simple templating output, but also the
> gathering of data from the model needed by the template (processing the
> sorting column, rows per page settings, etc).

That is a kind of haskell programming, what you do, a language I currently
learn. http://www.haskell.org. For only outputting the data without
altering the model that works. lib/div doesn't take this abbreviation,
because we want the ability to choice between different models and
views depending on given settings of the TS. Because of this any process
is controlled by the controller.

> 
> What I also miss in the current implementation of "view" in "lib": There
> is no intermediate layer between the controller and the view
> implementation "phpView". So if I would implement a "smartyView", I have
> to start from zero. What about having a generic abstract "tx_div_view"
> class that already implements everything that is not strictly "template"
> related? E.g. setConfiguration, setController, ..., asDate, asEmail, etc
> etc?

You are right. I was a little lazy in this point, because in the beginning
tx_lib_view and tx_lib_phpView would have been quite similar. Meanwhile
there are a lot of specific functions in the phpView. I set this on the
TODO list.

> - a view can declare itself as "dontCache()" and the frontend plugin
> controller will do the job of loading that specific view in an USER_INT
> object. So that the default in TypoScript is always "USER" but any view
> can overwrite that behaviour simply by returning true to "dontCache()".
> 

Sounds interesting, I need to think about it how usefull it would be and
if it would fit into the system.

> - a view (and its underlying templating engine) should have simple
> access to the URL generation routine that already takes into account the
> current prefixId. I currently don't see it happening in tx_lib_phpView.
> We could hold an instance of tx_lib_link in our plugin controller that
> already contains all parameters and prefix ID. We also need a way of

Yes that is a possible design. Making copies from it. Cheaper for the
memory would be to have a reset function and using the same object. Enough
to work on in the future.

> handling links between the same plugin spread over various pages
> (singlePid, archivePid, etc). I have central "pids" TS-setting in my
> extensions specifying where plugins for specific views are placed in the
> page tree. The link generation for a view should automatically find
> those. So basically calling this in a view:
> 
> $this->makeUrl(array('view' => 'single', 'uid' => $uid), 'singlePid')
> 
> would take into account prefixId for the parameters ("view" and "uid")
> and replace the destination with the plugin.tx_myplugin.pids.singlePid
> setting, if available. In that page we just need our plugin.
> 

This is very practical on the one hand and very specialized on the other.
I wouldn't at least implement that into the basical view classes. I would
like to have inherited classes, that offer support for this special
"baschny setup". For the beginning I would like to see such inherited
specialized solutions in independend extensions. After a while of
evaluation we would implement a little set of the most successfull of them
into lib/div. Not to much, only the best ones. Else people get an overdose
of features.

> - some way of handling multiple occurences of the same plugin in a
> single page (e.g. Single News in the content area and a "latest news" in
> the border column). The "defaultAction" is not sufficient in my eyes,
> because we have: processing actions and view output. In my solution I
> have a TS-setting for a plugin called "noAction" meaning that this

lib/div simply sets the action you want to use in the setup for the "non
processing" plugins, to do controll this selection. See my remarks above
and see this file:

<http://typo3.org/extensions/repository/view/efaq/0.1.0/info/configuration%252Fsetup.txt/>


Let us continue to exchange the ideas. You are one of the few that already
have refelcted and worked with this architecture.


 Regards

Elmar