[TYPO3-50-general] Beer3, really a good solution?

Niels Fröhling niels.froehling at adsignum.com
Sat Oct 25 20:08:35 CEST 2008

Sebastian KurfŸürst wrote:
>>> Personally I would be happy with server/client-side JS + XML + XSLT +
>>> XSL, though not every server has Rhino installed. It has the advantage
>>> to be a real abstraction, can be made to be really templatetative and is
>>> really well supported.
>  From my side, I do not want to code my templates in XSLT - that's a 
> powerful language, but hard to gasp for most people and really a 
> different paradigm than most of the standard ways.
Hm, that's not what I mean. You don't trigger XSLT, the CMS should. You 
don't program the Transform as a template-designer, the 
function-provider (core, extension, ...) does. XSL-T is for XML what the 
View is for MVC, it can Transform your (proprietary) input-template into 
a (standardized) output-result.
I meant that I prefer to use the existing XSLT Transform-mechanism (as a 
core/extension programmer), instead of having programmers (again) 
program a(nother) Transformation-Logic (again).

Also templates are not just only about FE web-page output. A select-box 
may be the result of a GUI-element template, tabs, lists, ... IMHO 
everything should tunnel through a template-engine (ever wanted editable 
select-boxes?, ever wanted to turn tabs into sequencial blocks in all of 
your CMS, just with a checkbox?).
> And, besides, the language is really verbose - so you sometimes need 
> lots of code for simple things.
Maybe. I like to basically be able to /program/ a whole GUI in a sandbox 
running in my FireFox without being connected to the internet, instead 
of re-loading a frame-content of the CMS all over again, or if that 
would have impact on data, to repeat all the steps to reproduce the 
test-case that bugged me.


More information about the TYPO3-project-5_0-general mailing list