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

[Ernesto Baschny [cron IT]]

Elmar HInz wrote: on 04.01.2007 08:38:

> the beta release 0.1.0 of lib/div is comming closer.

Hi Elmar,

that sounds very very promising and is already very cool. I haven't
followed the development for a while because I was involved in several
commercial projects. I enjoyed the way the MVC was implemented in "lib"
because that is basically very similar to the way I implemented it in my
own (commercial) projects!

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

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".

My solution and concepts are a slight bit different.

An "action" is just called if there is any "action" to perform
(update-model). A simple output of a view isn't an "action" to me, but a
view.

I have the main "plugin controller" (pi_base replacement). It's job is
to process any request:

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
(e.g. a new view to be loaded). I (and many other Web-applications) find
it important to redirect after a POST so that hitting "reload" won't
post the form again. In case of errors, we don't need to redirect, just
call nextView to display the errors (as reposting the form will just
trigger the same error again).

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).

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?

Some additions that I have in my framework that might be interesting in
"lib":

- 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()".

- 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
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.

- 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
specific plugin occurence will never process any update-model controller
(so that we don't handle the same POST request more than once!). I also
have a "view" TS-setting (for fixing a view, no matter what user-input
we have) and a "defaultView" TS-setting (for having a view if no other
instruction is given).

- ...

ok, probably some other stuff I want to tell, but I have to continue
working! :) So I wait for some feedback first...

Cheers,
Ernesto