[TYPO3-ect] Contnet rendering engine

[Jan-Hendrik Heuing]

> lets talk about a content rendering engine.
> 
> 
> History and today
> 
> We use HTML-templates and data arrays. Loops over the data need to be
> programmed for each extension again. There are no standards of output.
We
> need to adapt the HTML templates for each setup. We need to write CSS
for
> each setup.
> 
> 
> Tomorrow
> 
> * we don't need to program a view for each extension

But it should be possible if needed, so the kind of default would use
standard ways. I can think of those ways:

- Having a "standard render"
- Having a custom rendered template, which you set up with the extension
(sometimes iut's more useful than standard)
- Having a custom rendered template you can apply from the outside of
the extension, related to extension keys.

I got the idea of the last one, so you can have a template management
tool, where you have certain templates, but you can relate template
snippets to extensions depending on their extension key and other
things.

> * we just produce output of a defined standard
> * by selecting rendering templates we publish to different channels
> * we can select from different CSS styles to skin our page or make our
own
> skins
> 
> 
> Definition
> 
> The content rendering engine transforms standardized data input to
> standardized formats of output.
> 
> 
> Benefits
> 
> * reusibility of templates
> * reusibility or easy adaption of CSS
> * slim CSS
> * unique look and fell of extensions
> * improvement of usibility
> 
> 
> Example
> 
> A DB result set of addresses is rendered to a list view of addresses.
This
> list view could have different formats:
> 
> * slim accessible HTML with a minimum of markup
> * best stylable HTML with additional DIVs and classes for CSS styling
> * PDF List
> * old school table HTML
> * plain text list
> * list of microformats
> 
> 
> Use
> 
> Typically used for the view of extensions. I may have talked of a
generic
> view in the past to describe it. Either it may by the view itself of a
> library that the view is based on.
> 
> Formats of input
> 
> * XML
> * data objects
> * CSV
> * JSON

Do you mean heaving different formats for input channels, or do you just
offer those alternatives as a base for discussion?

I think that heaving many input types is great, but I guess maintaining
them takes a lot of time. So heaving less input-types makes sense to me.

On the other side, I would support the idea of heaving an interface
where you can add more input-types if you like. This is what I am
thinking about in some other situation right now... A converter between
different content types, which has some blackbox where things happen,
and the blackbox has got attachments in the form of webservices. You
call that converter with a configuration, which holds info on input,
output, and transformation in between. You can just push in input with
the same call, or you hand over information to use a custom webservice
to get those data, same with output. Example: You take sys_stat-data,
transform it, output apache-standard-log to remote (via webservice) or
just as a result back to the caller.
So, transforming that into different interfaces, having possibilities
like that seems interesting, but on the other side, it all takes more
time compared to doing things local I guess...

> Abstract level
> 
> Abstractly we can say, that we feed data and rendering templates into
it
> and get the output in return. We could define it as an abstract class
from
> wich different implementations could be inherited.
> 
> Existing technical solutions
> 
> Examples of rendering engines are the TYPO3 template functions, the
Apache
> project Cocoon, Smarty, ...  Depending on the kind of data input they
work
> with different technologies like XSLT or replacement of variables.

I quite like xslt, but I guess this is just a personal thing... Same as
I dislike smarty. But if anyone has some good reasons for any other
thing, I am open to anything. BUT: We need to work on this, templating
as it is now is just annoying.

> 
> TODO
> 
> To make it behave in standards manner we need to define standard
formats
> of
> input and output, decide for a rendering technology, implement it and
> provide the necessary rendering templates.
> 
> 
> How do we get it started?

Brainstorming I guess ;) Collecting ideas...

JH