Just an idea: Markup Wrapper

[Sebastian Gebhard-4]

Inspired by the discussion about "RFC: #11503: HTML5 doctype implementation"
and the lack of support of TYPO3 for valid HTML i came to this idea.

The markup of a TYPO3 page comes from different places like the page template,
TS settings, frontend-plugins, css_styled_content etc and is written down in
different formats like HTML Templates, TS-Wraps, hardcoded snippets in the core
and soon also Fluid Templates.

This shows that the overall markup is not very flexible, it's just impossible to
switch from a XHTML Website to a HTML Website.

My idea is to build an abstraction layer that allows to mark-up content independently
from the FE doctype.

Example1:
- Write [br] in the page template
- The Markup Wrapper will recognise all tags in [squared brackets]
- The Markup Wrapper will read config.doctype and generate the according markup
- It will return <br /> for XHTML doctypes and <br> for HTML doctypes

Example2:
- typoLink and all other core rendering features will create an [a] tag instead of <a>
- typoLink produces [a href="index.php?id=12&cHash=6786hsv4"]Linktext[/a]
- If doctype is xhtml_strict the Markup Wrapper will return <a href="index.php?id=12&cHash=6786hsv4">Linktext</a> else <a href="index.php?id=12&cHash=6786hsv4">Linktext</a>

Drawbacks:
- Invent a new markup language
- A lot of work to change all the markup in the typo3 world to that new markup language

Advantage:
- Full flexible doctype. You could change your Website's doctype with a single click
- New doctypes will be easy to implement. As the revival of HTML shows us: This can be a bug issue.
- A doctype other that xhtml_trans is difficult to accomplish by now, e.g. because extensions often generate XHTML Transitional Markup. With the wrapper the sites are indepentend from the extension markup doctype.

What do you think´?
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Oliver Klee-3]

Hi,

Sebastian Gebhard schrieb:
> Example1:
> - Write [br] in the page template
> - The Markup Wrapper will recognise all tags in [squared brackets]
> - The Markup Wrapper will read config.doctype and generate the according
> markup
> - It will return <br /> for XHTML doctypes and <br> for HTML doctypes

I'd prefer removing the hardcoded tags and have some HTML creator class
with different "flavors" using the Strategy pattern. This will allow
adding new document types practically without having to change existing
code.


Oliver
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[JoH asenau]

> Inspired by the discussion about "RFC: #11503: HTML5 doctype
> implementation"
> and the lack of support of TYPO3 for valid HTML i came to this idea.
>
> The markup of a TYPO3 page comes from different places like the page
> template,
> TS settings, frontend-plugins, css_styled_content etc and is written
> down in
> different formats like HTML Templates, TS-Wraps, hardcoded snippets
> in the core
> and soon also Fluid Templates.
>
> This shows that the overall markup is not very flexible, it's just
> impossible to
> switch from a XHTML Website to a HTML Website.

Exactly this is what XML/ XSS has been made for.
Just make sure TYPO3 produces clean XHTML (which is just a subtype of XML
anyway) and make sure there are proper XSS setups to translate this XML to
anything you like.

You can even use this to map tags or get rid of certain attributes as well.
Anything which is not defined in XSS will just be ignored/removed.

We did something like that 2 years ago while "translating" a table based to
a more flexible div based layout, because the code of this non TYPO3-project
was written in completely procedural and nested spaghetti-style.
We didn't touch anything of the original code except validating the X(HT)ML
structure and just mapped the tags and attributes to match the new design.

Advantages:
+ You don't need any additional or proprietary markup - just valid X(HT)ML
will do the job.
+ XML and XSS are accepted worldwide standards because they have been
introduced by the W3C long time ago
+ There are working XML and XSS parsing functions available in PHP
+ You can introduce other XSS setups to create completely different markup
i.e. to export calendar data to iCal or the like
+ The XML/XSS interpreter can be run on completely different servers acting
as a real frontend, while the backend server will be delivering the same
X(HT)ML to each of them. Caching will be childs play with such a setup.

Just my other 5 cents

Joey

--
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com


_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Xavier Perseguers]

Hi Joey,

You mispelled XSL as XSS (cross site scripting) ;-)

Regards
Xavier

JoH asenau wrote:

>> Inspired by the discussion about "RFC: #11503: HTML5 doctype
>> implementation"
>> and the lack of support of TYPO3 for valid HTML i came to this idea.
>>
>> The markup of a TYPO3 page comes from different places like the page
>> template,
>> TS settings, frontend-plugins, css_styled_content etc and is written
>> down in
>> different formats like HTML Templates, TS-Wraps, hardcoded snippets
>> in the core
>> and soon also Fluid Templates.
>>
>> This shows that the overall markup is not very flexible, it's just
>> impossible to
>> switch from a XHTML Website to a HTML Website.
>
> Exactly this is what XML/ XSS has been made for.
> Just make sure TYPO3 produces clean XHTML (which is just a subtype of XML
> anyway) and make sure there are proper XSS setups to translate this XML to
> anything you like.
>
> You can even use this to map tags or get rid of certain attributes as well.
> Anything which is not defined in XSS will just be ignored/removed.
>
> We did something like that 2 years ago while "translating" a table based to
> a more flexible div based layout, because the code of this non TYPO3-project
> was written in completely procedural and nested spaghetti-style.
> We didn't touch anything of the original code except validating the X(HT)ML
> structure and just mapped the tags and attributes to match the new design.
>
> Advantages:
> + You don't need any additional or proprietary markup - just valid X(HT)ML
> will do the job.
> + XML and XSS are accepted worldwide standards because they have been
> introduced by the W3C long time ago
> + There are working XML and XSS parsing functions available in PHP
> + You can introduce other XSS setups to create completely different markup
> i.e. to export calendar data to iCal or the like
> + The XML/XSS interpreter can be run on completely different servers acting
> as a real frontend, while the backend server will be delivering the same
> X(HT)ML to each of them. Caching will be childs play with such a setup.
>
> Just my other 5 cents
>
> Joey
>

--
Xavier Perseguers
MVC ExtJS Leader

http://forge.typo3.org/projects/show/extension-mvc_extjs
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[JoH asenau]

> You mispelled XSL as XSS (cross site scripting) ;-)

ooops - of course I meant xsl:stylesheet.
Maybe kind of freudian slip due to the fact that we are currently trying to
fix a lot of security holes in a custom made extension for one of our
clients.

Thx for the warning ;-)

Joey

--
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com


_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev