[Typo3-dev] TS inconsistencies...

[Johannes Reichardt]

Hello!

Just my 2 Cents (hey with € in germany :) on this topic.

What i´d like to see  changed in the long run is such "superspecific"
typoscript snippets that manage to add a stylesheet for example. Just
things
that do very very simple html coding for you but could be done by simply
adding a html tag as well. 

just for the peace of cleaner code and less not-so-much-necessary
redundant
tags.

what you think?


> -----Original Message-----
> From: typo3-dev-admin at lists.netfielders.de 
> [mailto:typo3-dev-admin at lists.netfielders.de] On Behalf Of dan frost
> Sent: Donnerstag, 24. Juli 2003 10:28
> To: typo3-dev at lists.netfielders.de
> Subject: Re: [Typo3-dev] TS inconsistencies...
> 
> 
> Here's my suggestion - and bear in mind, I think this is a 
> _long-term_ 
> aim for the good of TS.
> 
> TypoScript should be entirely defined in objects. Each 
> datatype, content 
> object and all other TS 'things' should be defined by 
> inheritance in a 
> properly organised object-oriented structure. I'll explain 
> why at the end.
> 
> For example:
> 
> Datatypes - because these generally define the way a "thing" works, 
> datatypes could be implemented as interfaces (if available in 
> PHP5 - or 
> psuedo-interfaces, if no).
> 
> The parent object - would look be very based. It would 
> probably contain 
> just a simple interface and a "debug" function.
> 
> E.g. TEXT - would inherit from the parent, adding methods and 
> interfaces 
> as needed.
> 
> E.g. HTML - would inherit from TEXT, also adding as needed.
> 
> E.g. IMAGE - would inherit from a 'graphics' object (probably 
> also the 
> parent of gifbuilder and the like), which would use HTML (to fake 
> multiple inheritance).
> 
> The point of this is three-fold:
> 1. Objects and easier extensible. Datatype, content-type and 
> whatever-extensions could be written to extend _just_ the 
> necessary class. 2. Any PHP-object analyser (e.g. 
> http://www.ueckermann.de/typo3doku/) 
> would automatically act as a TS reference, showing what methods, 
> functions and properties are available to any "thing".
> 3. Inconsitencies would be explainable in terms of this structure.
> 
> Also - it's more organised, and (if it's of interest) would make it 
> (relatively) trivial to implement a TS-debugger, or to port 
> TS (e.g. a 
> Java TS rendering engine; or native-code, for bigger sites).
> 
> Again, I emphasise that this is a long-term aim. Organising 
> TS like this 
> makes sense, long term, especially with the explosion in the 
> number of 
> extensions (each adding more "things" to the language). Implementing 
> this needn't be hard, though - it would start by moving all 
> the code to 
> properly organised objects-files (which are include()'d by 
> the existing 
> TS-rendering file).
> 
> If anyone's not convinced, I could mock-up a few examples.
> 
> Any thoughts?
> 
> dan
> 
> 
> 
> Peter Niederlag wrote:
> 
> >Hi Dan,
> >
> >dan frost <dan at danfrost.co.uk> schrieb :
> >
> >  
> >
> >>I haven't been doing TS for as long as many of you, but compared to
> >>learning PHP in a few days, TS is taking an age to master...
> >>    
> >>
> >
> >I partly agree on that but to me it seems that this is rather due to 
> >the fact that the overall picture of Typo3 was missing to me. 
> >Toplevel-object Config, BE-TsConfig, PageTSConfig. 
> >TS-Setup/TS-Constants...Static Templates...Include before Static, 
> >isRoot, ...
> >
> >with just about half a year of PHP-experience, that was 
> driving me nuts 
> >at first!
> >
> >But hey, if you have ideas for improvements, that would be great!
> >
> >PeterN
> >  
> >
> 
> 
> _______________________________________________
> Typo3-dev mailing list
> Typo3-dev at lists.netfielders.de 
> http://lists.netfielders.de/cgi-> bin/mailman/listinfo/typo3-dev
>