[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Typo3-dev] ObTS - answers to questions (was: [Typo3] Accessibility and Typo3)
- From: dan at danfrost.co.uk (dan frost)
- Date: Tue Jul 12 01:17:14 2005
> I`m also waiting for Dan Frost's OO-TS. This sounds really great. First - my laptop has broken, putting me back by at least a week. Sorry about this - i'll get back on track asap. Also - anyone (preferably in england) know a linux-friendly laptop supplier who builds on site/in the country?? Second - this is in reply to an email on the english list, but is copied to the dev list to answer some questions. Ok - I will now try briefly to describe how ObTS will work, what it will do, what it won't do and what problems it will cause. I will make reference to the (existing) source code. TypoScript was, Kasper has told me, originally design to configure a very few variables. It has since grown to be what some have called a "language", although the issue remains contentious. This beginning and this grown explains perfectly why it appears "inconsistent" and, to the new comer, behaves strangely at times. Having spent some time arguing on the dev-list, I said i'd go away and work on an alternative. Kasper encouraged me to think of my project as a different thing entirely, but I'm not sure I have done. These were some of my thoughts: - TypoScript is a system (language) of configuring webpages - TypoScript is very useful for non-phpers and phpers with little time - TypoScript offers an interface to programming-code for non-programmers, enabling them to use complex programs and code (e.g. extensions) - TypoScript implies OO programming because different datatypes use the same, or similar functions; different datatypes often behave in similar ways; the code in tslib_content.php is similar from datatype to datatype. - Because TypoScript uses the datatypes (listed in the huge switch statement near the top of tslib_content.php) we can regard TypoScript and the datatypes as the thing which determines what the html is like. Here are the features of my system (at present): - make a "TypoScript class" which describes how all TypoScript "object" behave. This is ts_object in my system. - Implement TypoScript objects as children (i.e. child extends...) which define how the particular child behaves and what it looks like. These are classes "tso_sometype" in my system. - Implement a layer of abstraction between markup (html) and logic (typoscript). - Implement all functions as php functions, and make them available to all datatypes, at all levels - Improve debugging - in the finished system, you will be able to click on part of the (preview) page and see the configuration of that object; there will also be c4 debug levels: none, to log, to content, to admin panel. - A backdoor - some of the internals of TypoScript (e.g. the arrangement of html tags and placing of data inside them) 'appear' to be built in TypoScript. I have built a "backdoor" function which gives TypoScripters access to the internal configuration of each TypoScrip datatype. This can also be used for building new (light-weight, low logic) datatypes - Because TypoScript objects/datatypes are implemented in a modular way, it will be possible to give non-admin users access to some of typoScript (e.g. text, image, and no database functions..). And what of xhtml and accessibility: - The layer of (logic-markup) abstraction will ensure that each element of mark-up is good xhtml. It does this by using a php-array version of the xhtml DTD - it _will not_ render bad xhtml, because it can't (unless explicitly forced). - There wil be "templates" used in the Form datatypes for things like <input../>, meaning that unless the TypoScripter forces the system not to, the input will be rendered with the input tag will always be rendered along-side a <label../> (See WAI guidelines) - TypoScript objects don't return (i.e. make) html - them return mark-up objects. This means that, at each stage in building the page xhtml will be forced. - In short: it will be able (if configured properly) to force xhtml compliance and, by using templates for some tags, accessibility. It will also, because of the debugging feature, be able warn when it generates something which might not be accessible. So, Kasper, why have i implemented this as a replacement for TypoScript, and not a completely different system? The reasons are: - my employer wants all TypoScript to be like Object-TypoScript - I realised that "hi-jacking" the data-type calls from the switch statement in tslib_content.php is quite easy and - Implementing different datatype in the system is, i found, quite simple. So - that's (some of) it so far. This is how I plan to proceed. Future development plan #1 - I plan - and hope - to release the beta version in the next couple of weeks. (See laptop problem at start). This will be implemented as an extension (installed normally) and a patch (slight change) to tslib_content.php. #2 - Once the parent "TypoScript class" is nearly finalised and it's behaviour is settled, anybody else can work on datatypes. I have already written most of the documentation on how to build new datatypes, new functions, and implement new XMLs etc. If people are interested, I will set up a CVS server where developers can add new types, but only a few can change the parent "TypoScript class". FYI: building a new datatype is pretty damn easy. Once the datatype is installed on a system, it is automatically available and can be tested. FYI2: it would probably be possible to implement some extensions as simple TypoScript functions - e.g. to add example.getFromNewsFeed = url://..... #3 - move the existing data-types over to ObTS. (Group effort). #4 - build new data-types (Group effort). I expect that we could start seeing a stable, and easily used extension by the end of January. Some things which might be nice, and are made quite easy in ObTS: - An XML implementation of ObTS to allow other tools to be used - a GUI for ObTS - A TypoScript "content element", or similar so typoScript benefits from the versioning, user-permissions and so on that real content elements have I'm sorry to blast this out in one go, and before i've released it. I hope this answers lots of questions. I have almost got ObTS stable, but it's not been easy or quick. Thanks for you patience... Regards, dan P.s. I would like to thank Synergy Communications, who are paying for all of this work, and everyone who argued with and supported me some 5 months ago on the dev list.
- Prev by Date: [Typo3-dev] Typo3 and Images
- Next by Date: [Typo3-dev] Problem in implementing menu in the subpages.
- Previous by thread: [Typo3-dev] Postform is not coming in guestbook although postform is implemented.
- Next by thread: [Typo3-dev] Problem in implementing menu in the subpages.