[TYPO3-ect] Improvement of the template engine

Kasper Skårhøj kasper2006 at typo3.com
Fri Jan 27 12:03:22 CET 2006


Hi Elmar,

The steps you describe is _exactly_  the sort of Template API I would  
love to have.

of various output handles I could imagine (but not limited to of  
course):

- Hardcoded HTML with CSS styling according to some TYPO3-defined  
standard (for out-of-the-box usage of plugins for people who are not  
interested in own templating. This is like the kickstarter makes it  
now, only better thought through classes / HTML).
- Classic HTML markers
- TemplaVoila
- Smarty
- XSLT?
- TypoScript

- kasper



On Jan 26, 2006, at 23:16 , Elmar Hinz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Respect!
>
> 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.
> 2.) You pass this to a function that does the rest.
> 3.) This function offers it for different usages: Htmltemplate, TS,  
> Smarty, ...
> 4.) You can deploy new output tools as extensions. They are  
> registered as
> services to the function.
> 5.) Every team can choose the tool that matches best.
>
> Right?
>
> How can we integrarte this into the MVC framework based on a forms  
> library?
> It is he mayor part of the view.
>
> Regards
>
> Elmar
>
>
>
>
>
>
> Ernesto Baschny [cron IT] schrieb:
>> JoH schrieb am 26.01.2006 00:36:
>>
>>
>>>> the classical template maker looks like this:  
>>>> ###PROJECT_ABSTRACT### .
>>>>
>>>> "<h3>###PROJECT_ABSTRACT###<h3>"
>>>> If the project name is empty the resulting output is "<h3></h3>".
>>>>
>>>> (...)
>>>>
>>>> What do you propose the best direction to go with templating  
>>>> features?
>>>>
>>>> A) Extending the ### System?
>>>> B) Develope of an XML variant?
>>>> C) Implementing smarty or a simlar tool more officialy?
>>>> D) Other idea
>>>> E) Doing nothing
>>
>>
>>> D)
>>> Don't use markers to replace the content inside a tag.
>>> Use wraps instead and markers without a tag.
>>>
>>> HTML-Template
>>>
>>> ###MARKER1###
>>> ###MARKER2###
>>>
>>> TS-Template
>>
>>
>> I would suggest: extension developers shouldn't use html-templates at
>> all. It should be up to the site implementator if he wants to use  
>> pure
>> TypoScript, html-templates or other methods for rendering plugins
>> output. You just need to provide a consistent and documented set of
>> cObjects and stdWraps so that one can do whatever he wants with  
>> the data
>> your plugin provides (which would mean a real separation of data
>> generation and data rendering):
>>
>> PHP-Code (something like this...):
>>
>> function singleView() {
>>   $row = getMyDataRow();
>>   $this->local_cObj = t3lib_div::makeInstance('tslib_cObj');
>>   $this->local_cObj->start($row, 'my_data_table');
>>   $content = $this->local_cObj->cObjGetSingle($conf['detailView'],
>> $conf['detailView.']);
>>   return $content;
>> }
>>
>> TS-Code with pure TypoScript templating:
>>
>> plugin.my_plugin {
>>   detailView = COA
>>   detailView {
>>     10 = TEXT
>>     10 {
>>       field = title
>>       wrap = <h3>|</h3>
>>       required = 1
>>     }
>>     20 = TEXT
>>     20 {
>>       field = bodytext
>>       wrap = <p>|</p>
>>       required = 1
>>     }
>>   }
>> }
>>
>> TS-Code with the given HTML-template (marks/subparts):
>>
>> plugin.my_plugin {
>>   detailView = TEMPLATE
>>   detailView {
>>     workOnSubpart = SINGLE
>>     template = FILE
>>     template.file = EXT:my_ext/res/template.html
>>     marks.MARKER1 = TEXT
>>     marks.MARKER1 {
>>       field = title
>>       wrap = <h3>|</h3>
>>       required = 1
>>     }
>>     marks.MARKER2 = TEXT
>>     marks.MARKER2 {
>>       field = bodytext
>>       wrap = <p>|</p>
>>       required = 1
>>     }
>>   }
>> }
>>
>> The idea of this is to be able to get rid of all "html-templates" as
>> files in the fileadmin area, which are a pain for me to manage (no
>> versioning, etc), which is why I would love to be able to have
>> everything in database.
>>
>> We could even use this scheme in existing extensions like tt_news and
>> still maintain backwards compatibility: The defaults provided in
>> plugin.tt_news should just use the existing html-templates, but this
>> should be done in TypoScript instead of in PHP, so one can swap to a
>> different templating scheme at will.
>>
>> Cheers,
>> Ernesto
>
>
> - --
> Climate change 2006 is killing people: floods in California,  
> drought and fires
> in Australia, Texas, Sahel, Oklahoma, South Africa. The Bush  
> administration is
> responsible for corruption of the Kyoto Protocol. The US majority  
> is responsible
> to the world for reelection of a convictable [...censored by  
> Echelon...].
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFD2UovO976RNoy/18RAp2rAJ9N6ceZr5152y4D/OhSm0WRQFxmcgCggawY
> b5DSs9lTaPtRseI7TfnQ5Xw=
> =vSrS
> -----END PGP SIGNATURE-----
> _______________________________________________
> TYPO3-team-extension-coordination mailing list
> TYPO3-team-extension-coordination at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team- 
> extension-coordination




More information about the TYPO3-team-extension-coordination mailing list