[Typo3-dev] ObTS ready.

Martin Poelstra martin at beryllium.net
Tue Dec 16 11:29:46 CET 2003


Hi Dan,

On Mon, 2003-12-15 at 18:45, dan frost wrote:
> > Fatal error: Call to undefined function: cobjgetsingle() in
> > /var/www/testsite/typo3conf/ext/obts/tslib_content/class.tslib_cobj_stdwrap.php
> > on line 1062
> Probably related to the piece of undisclosed, essential information: 
> this is for version 3.6.. Sorry.

Ok, going to install that in a few days anyway :)

> I'll double check this error asap.

Tnx.

> Auto-complete, prompts for available function names, properties, 
> datatypes and so on are all possible and relatively simple of ObTS.
> 
> I will, now be able to come of the snowboard tour and plan to demo how 
> this is possible.

Well, I won't be there, but I'd love to here from it when you worked it
out!

> You don't need a setupWML() - you (or, rather I) just need to 
> implement a better setupHTML() and perhaps rename it setupML() or 
> setupOUT().
> 
> Basically, setupHtml() uses an API to a mark-up rendering objects. 
> This class knows nothing about any particular mark-up/XML; that is, it 
> know only about make well-formed xml, not valid (right way round, i 
> think).
> 
> To implement another xml, you could do:
> (a) Use setupHtml() as usual
> (b) have a "mapping" function which maps between different xml. This 
> works on the result of setupHtml() and is this on a per-datatype basis.
> 
> Or, (b) could happen at the mark-up rendering level. I'm not sure 
> which is best yet, but will try a few.

Hmmm, when I was just about to fall asleep I got an idea: I think it
would be quite inefficient to first translate to XML, and then back to
e.g. WML, because it would probably involve lots of regex's.
Now, the input to setupHTML is some arrays with tags and attributes.
Wouldn't it be nice to have a completely seperate set of classes (the
render-classes) that actually transform these arrays to HTML, WML, XML,
whatever?
I don't know exactly if the current tag/attr-arrays are 'general'
enough, maybe they should be changed slightly to be less HTML-biased
(more XML).
This way it is possible to directly generate the correct output-format,
('plain' HTML, XHTML, WML, XML, etc.) independantly from the
TS-datatypes.

Or am I now completely missing the point here? ;)

> P.s. I am going to launch a site on how ObTS works - it makes it a bit
> easier to understand. Also, i'll add each API/program flow to it over
> time.

Maybe you could provide a (simple) document that states what exactly
'stays the same' (like you (currently) still use the Setup-field of
'normal' templates), and what changes, thereby trying not to get to
technical. This way you already have a slight understanding of the
concept when starting to read the rest of the documentation.

Grtz,
Martin






More information about the TYPO3-dev mailing list