[TYPO3-dev] RFC: Change roadmap for 4.5 and 5.0

[Ries van Twisk]

>On 4/10/06, Michael Scharkow <mscharkow at gmx.net> wrote:
>  
>
>>Christopher wrote:
>>
>>    
>>
>>>I'm honestly bewildered by the claim that it's difficult to switch
>>>between xhtml and html in code generation: given that TYPO3, when it
>>>outputs markup at all, is not checking for validity or
>>>well-formedness, the entire extent of the problem is limited to
>>>doctypes, the decision to include--or not--closing tags on 'empty'
>>>elements, and differences in attributes (e.g. target and border). If a
>>>doctype is set using ' config.doctype = ___ ' then a simple check
>>>seems to be all that's needed when outputting closing slashes and
>>>attributes. And there are only a few elements where even _this_ would
>>>be needed (meta, img, br, base...)
>>>      
>>>
>>I agree that the problem itself is trivial: You simply check if
>>xhtml==true and add a slash, or sth. like that. But if you want this
>>feature to be used consistently, you have to abstain from writing any of
>>the concerned tags in your views, be it in hardcoded php or some
>>template language. Instead, you're forced to write wrappers like
>>renderTag('img',$src='foo', $class='bar') which I don't find
>>particularly elegant, but some die-hard JAVA users or TS gurus might.
>>    
>>
>
>I don't know whether to think a wrapper is elegant or not, but I _do_
>think that building an html tag in code every time you want one is an
>extremely cumbersome style of coding.
>
>In any case the attributes could be done with a wrapper (there might
>be no alternative), but for the tag-closing slashes, presumably you
>could simplify things:
>
>echo '<img src="' . $src . '" . $closingTag . '>';
>
>...where $closingTag is the value of some flag (like the TS flag used
>to enable / disable the 'border' attribute on images) that can be set
>in the BE:
>
>// Assume xhtml if you prefer:
>$closingTag = ' /';
>// But consider the alternative:
>if (xhtml == true) {
>  $closingTag = '';
>}
>  
>
Why not do it object oriented?
class html  {
  function getTag_Img(....):
 function getTag_Br() { return '<br>';}
}

class xhtml  {
  function getTag_Img(....):
 function getTag_Br() { return '<br />';}
}

class xhtmltrans extends xhtml  {
  function getTag_Img(....):
 function getTag_Br() { return '<br />';}
}

When you start Typo3 simple initliase the right class for the needed 
rendering
method, simple fast and extreemly elegant.
Then we can get rid of tese if/then/else/ButWhatIf/ButAlsoIf constructs
This will speed up rendering to.

Note, for some tags and the BR example above might not be the best example
to create constant for it. This will eliminate quite some function call. 
Speed over design...
But when people use getTag_Br() it is always fine. (we can make 
getTag_Br() private to force
people using TAG_BR).

define('TAG_BR', $htmlrendered -> getTag_Br());

Ries

>A single variable then, could be included into every instance where
>and img, meta, base or br is genenerated. I have no real idea if this
>could be a performance problem, but since we cache most content
>anyway...
>
>  
>
>>Alternatives would be a) post-processing of output (aargh), b) separate
>>templates for HTML and XHMTL (like to different versions of CSC) which
>>does not scale very well, c) choosing just one supported HTML version.
>>    
>>
>
>(a) is ugly, you're right...
>(b) given that this whole discussion is about relatively few elements,
>this might not be such a bad idea...I can't quite grasp what you're
>thinking of though. Care to elaborate?
>(c) is, IMO, just not a good option--espeically given that 1) TYPO3 is
>supposed to be capable of outputting non-html (e.g. plaintext, xml,
>wml...) content and 2) there is at least the _possibility_ of new
>(i.e. non-w3c) varieties of (x)html [1]
>
>  
>
>>I could not care less about whether to use HTML or XHTML in whatever
>>version (unless there are some legal requirements for this, as I vaguely
>>remember in Germany's BITV, might be wrong though) as long as we don't
>>need to support two incompatible versions.
>>    
>>
>
>The problem of supporting multiple versions is _exactly_ the reason
>why I think the html needs to come largely or completely _out_ of the
>core--or at least be rationalized. We actually have SEVEN current
>markup versions now [2], not two--even if you only count xhtml
>flavours, there are still THREE variants to contend with...
>  
>
It think a truly object oriented way is the only good solution to do it.
For each render method we created a class set.
This will make the core really nice and clean.

>
>-Christopher
>
>
>[1] http://whatwg.org/specs/web-apps/current-work/#html5
>[2] http://www.w3.org/QA/2002/04/valid-dtd-list.html
>_______________________________________________
>TYPO3-dev mailing list
>TYPO3-dev at lists.netfielders.de
>http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
>  
>


-- 
Ries van Twisk
Freelance Typo3 Developer
=== Private:
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk
=== Work:
email: ries at livetravelguides.com
web:   http://www.livetravelguides.com