[TYPO3-dev] Extensions with more TS support

[Franz Koch]

Hi Joey,

>> +1, but I'd go a bit further and implement it the way cal is doing it
...
>> no overhead.
> 
> Well - this is not going "further" but would be the default behaviour if
> people would start using TypoScript the way it was meant to be. Which is not
> the case for cal as well as for so many other extensions.
> 
> plugin.blah = USER
> plugin.blah {
>     userFunc = className->mainFunctionName
>     renderObj = TEMPLATE
>     renderObj {
>         template = FILE
>         template.file = blah
>         subparts {
>             SUBPARTNAME = COA
>             SUBPARTNAME {
>                 10 = USER
>                 10.userFunc = className->functionName
>             }
>         }
>         marks {
>             MARKNAME = COA
>             MARKNAME {
>                 10 = USER
>                 10.userFunc = className->functionName
>             }
>         }
>     }
> }
> 
> This will use the subpart SUBPARTNAME and the mark MARKNAME only.
> If you need more, simply put them into your TS template, add the necessary
> functions to your class  - done!

Well yes, but if somebody is removing the marker "MARKNAME" from the 
templates, TYPO3 will still process and try to replace it, right? So you 
get overhead. My suggestion is going the other way around and would also 
allow to define some default rendering objects that could be overriden 
from case to case, without extensively copying TS-objects around and 
blow up TS-setup unnecessarily.

> If you need wraps, stdWrap functions or other stuff to be applied to your
> marks and subparts, simply add them to the corresponding COA.
> If you want to enable or disable caching, make it a COA_INT or a USER_INT
> instead.

Those are in my eyes the only advantages of the "traditional" TS way, to 
be able to wrap any subpart via TS and make them ..._INT on demand. But 
making whole subparts ..._INT might only be needed in rare occasions. 
And the TS of complex extensions with various views using TEMPLATE 
objects for rendering might become a beast you barely can keep control 
off. For more simple extensions I agree that this would be the way to go.

> If you need language support, just do something like the following and to
> make these values editable for admins, fill in some constants and make them
> available with the constant editor.
> 
> Setup:
> marks.MARKNAME = TEXT
> marks.MARKNAME {
>     value = Default value
>     lang {
>         de = {$markname.german}
>         en = {$markname.english}
>     }
> }
> 
> Constants:
> #cat = plugin/marks/1; type=text; label=Mark name english
> markname.english = an english text
> #cat = plugin/marks/2; type=text; label=Marker Name deutsch
> markname.german = Ein Deutscher Text
> 
> This works even for FORM values and labels.
> 
> Life could be so easy for extension developers if they just tried to
> understand TypoScript first.

I know, understand and love TS, that's why I provided patches for cal to 
have it make use of TS in a far more flexible way then before (which was 
ugly tt_news style). But your suggestion has in my eyes some downsides:

Using "stdWrap.lang.l10nKey = {$constant}" will work, but is much harder 
to maintain and modify for more complex TS-objects than in your example. 
Example:

plugin.extKey {
   view.markers {
	MARKNAME = TEXT
	MARKNAME {
		field = db_field
		typolink {
			parameter.field = db_field
			title = %%%click-for-details%%% '{field:db_field}'
			title.insertData = 1
		}
		wrap = <dl><dt>%%%link%%%:</dt><dd>|</dd></dl>
	}
   }
   _LOCAL_LANG {
	default {
		click-for-details = Click here to see more details about
		link = Link
	}
	de.some-title-text = Klicken Sie hier für mehr Informationen über
   }
}


Doing it your way would make the TS much more complicated and way harder 
to understand and modify for users with "regular" TS knowledge. I prefer 
stuff that is easy to understand and handle. But that's my personal taste.

-- 
kind regards,
Franz Koch

---------------------------------------------------
PayPal-Account: 'paypal _at_ elements-net _dot_ de'
---------------------------------------------------