[TYPO3-ect] Improvement of the template engine

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 26.01.2006 23:16:

> Let me catch and concretise your idea:
> 
> 1.) You organize the output as a  array or XML (values, labels, errors,
> comments, helptext, ...) of a standard format.

In my idea one would catch these information in a cObject (data-array).
This way we can use regular stdWrap/getSingleCObject/etc methods to
process the data. But I see that there are limitations: the cObj->data
is a one-dimensional array field=>value.

So if we want to have arrays, be able to loop through arrays, pass
arrays to Smarty, etc, we need to extend the functionality of cObject
and stdWrap.

> 2.) You pass this to a function that does the rest.

You use tslib_cObj::stdWrap and tslib_cObj::cObjGetSingle to have the
data rendered (stdWrap to transform each item/element, cObjGetSingle to
render the complete "view").

HOW the rendering is done is chosen through TypoScript which is
configured by the user (or provided by the extension itself or some
other extension).

> 3.) This function offers it for different usages: Htmltemplate, TS, Smarty, ...

Just look at chapter 8 of TSref to see what content objects you can
generate with cObjGetSingle! Its already there.

> 4.) You can deploy new output tools as extensions. They are registered as
> services to the function.

No. You just need to change the TypoScript that configures the rendering
of your plugin to generate other type of output. No service, no other
method needed. This can already be done with TYPO3, and this is how I've
been doing lately in my extensions.

If you take a look at the css_styled_content from beta2 you will see my
CSS styled IMGTEXT integrated. And you will see the .layout property.
This is just a cObject that decides how the output of the IMGTEXT will
get layed out. Currently its a "CASE" object based on the imageorient
property, but one could change this to any cObject available to TYPO3.

E.g. I could render the single view of tt_news using the IMGTEXT cObject.

This is where ObTS comes into action: The nice thing about ObTS is that
you can create new TS-cObject types! So we could have SMARTY cObjects or
other rendering methods this way.

> 5.) Every team can choose the tool that matches best.

That's right. The extension author could provide an example
HTML-template based rendering. So nothing changes if you are used to
HTML-templates. But one can change that using TypoScript. Other
extensions can just provide alternative TypoScript to render ones
extension output.

> Right?
> 
> How can we integrarte this into the MVC framework based on a forms library?
> It is he mayor part of the view.

Hm, I see the "Templating" part in the FE-Forms wiki page. I can imagine
that we can keep the rendering of forms TypoScript based, so that we can
support HTML-templates, Smarty-Templates, etc. We already have a FORM
TypoScript cObject, which might be enough for simple cases (might need
some tweaks to allow such other "uses" of it) but we might want to have
more complex FORM-TS-Objects.

And having this configurable through TypoScript adds yet another
dimension of possibilities: You can now have different output for your
plugins depending on TS-conditions (browser, device!), without the
ext-author having even to think about it.


Cheers,
Ernesto