TYPO3 Core

I've added a patch that adds this behavior to the sysext cms. I'm not sure if this is all what is necessary but it looks good for me...

Greets,
Thomas

thanks a lot

Have you tested it?

i just testet the patch ant it does what i expect for config.linfvars.xxx but. it must be checked before weather the config.linkVars. array exists.

if ( isset ( $GLOBALS['TSFE']->config['config']['linkVars.'] ) ) { ...

otherwise the implode function will cause an error

regards Martin

I don't like the idea of this patch because this would make sense for quite a lot of other keys, too.

I rather suggest to look for a solution to add a value to an existing key, like it is done in PHP:

config.linkVars = L
config.linkVars .= testVar,myVar

So finally, config.linkVars should be: L,testVar,myVar

What do you think?

i fear that the ".=" solution has even more impact on existing installations and i'm not shure wheather the new behavior will be understandable for not advanced users since a missing "." will break the typoscript configuration.

your point is good that the csv-list configurations is used not only there but i think that this behavior is no good style at all, so i would prefer to change to config arrays instead of config csv-lists wherever possible.

i cant see an big performance difference between these two methods and for my personal purpose both would be ok. i just wonder wich method will be more undestandable for others.

the patch above uses the implode function to add the array code to the value and short afterwards the string is exploded again, that is indeed not the best solution it would be better to use the already parsed typoscript array and to append the values from the old csv. that could move parsing(expoding) of ts-code from the pagegen-class to where it belongs, the typoscript parser.

regards Martin

Martin, I think that the key/value pairs are an overkill. Just treat the keys (vars) as booleans

config.linkVars = L
config.linkVars.myVar1 = 1
config.linkVars.myVar2 = 1

Michael, I support the idea of concatenation in TS, but I'd use someting more familiar than a dot. IMHO a simple plus sign should be sufficient:

config.linkVars = L
config.linkVars + ,myVar

I just uploaded bug_1722.diff, it contains a little patch that can add values to an existing property using a "+" instead of a "=".

Make sure to add a comma in front of the value if it is a comma separated list.

I think this is just an experimental solution, I don't like it very much because the TS code will look a bit ugly:

config.linkVars = test
config.linkVars + ,blabla

If anybody has a better solution for concatenating properties, please make a suggestion here.

Hi Masi,

config.linkVars = L
config.linkVars.myVar1 = 1
config.linkVars.myVar2 = 1

You may remember my mail from the core list: This will not work! The config TLO is only one-dimensional, there are no subarrays.

The reason is that config and page.config are merged using an array_merge function, and guess what, this function does not work recursively!

So this example will break in TypoScript:

config.linkVars.myVar1 = bli
config.linkVars.myVar2 = bla
page.config.linkVars.myVar1 = blubb

(although I didn't test what the result of it will be...)

Michael, I forgot about the no-arrays-in-config problem. Bit that does not only invalidates my suggestion but also Martin's original suggestion.

And as for uglyness, is += any better? It may have some appeal for programmers but is by no means more beautiful. OTOH this could lead to an extension:

var = val
var =+ ,val1
var += val2,

Now "var" has the value of "val2,val,val1".

The idea is that the position of the + sign signifies the position where the string shall be added. This is useful because you cannot do $x = "a".$x in TS.

This will lead to another problem. How will you set the pagetitle for example to "++ mypage ++"?

The problem is that as long as only the first character is used, we can be sure it is the operator. But what happens if there is a 2nd, or more characters?

BTW I didn't think about the plus sign when saying that is is ugly, I rather thought about the comma that is added although it is clear that this is a list.

I think the best solution will be some method like the constants access. Would it be a solution if {$myVar} in the setup accesses the constants (already existing), but if used in the constants, it accesses another existing constant? Example:

Constants:
myVar = test
myVar = {$myVar},value2

Setup:
config.linkVars = {$myvar},value3

What do you think?

1. maybe the config problem can be solved making the option a stdWrap. thats not a general solution to the csv poperty problem but would enable users to create more flexible statements. ( using stdWrap.cObject = COA or so)

2. the ideas about the "+" options for ts are interesting and could improve the typoscript but it is a syntax change and schould be handled with care.

3. i see that the named configuration arrays i suggested are not really a good way but they are used several times now ( includeLibs, includeCSS ) imho it would be better to find a ts-expression for appending a value to an array without defining a name that would also prevent problems with names used more than once.

mabe something like that can be creted

page.includeLibs << foo
page.includeLibs << bar

['page']['includeLibs.'][0=>"foo",1=>"bar"]

i dont think that << is the best operetor for that i think we can find a better one

regards Martin

PS: also must be noticed that 0 is nout really a good key in typoscript since it is often not used or ignored by if ($value) statements so mabe the use of key 0 should be supressed. i had some strange effects when trying to write a case statements with a key 0 ( bug id 0001736 )

@Michael & Masi:

The config and page.config seem to be merged not with array_merge, but simply by traversing the page.config and setting the config[$key] each time (TSFE->getConfigArray()). Apart from performance, there's no reason we could not use t3lib_div::array_merge_recursive_overrule() to do that.

@Martin:

you cannot use stdWrap in the CONFIG object, as at the time of parsing this, there isn't a content object yet, so we have no stdWrap functionality.

@all review:

I also agree that a TS syntax change has to be chosen with care to detail, and we should discuss if more operators are welcome to TS or if the lack of them is what makes TS so unique.

We could have a PHP-like syntax:

; push another item to an array:
temp.obj[] = item

; append a string to an array:
temp.str .= string

etc. This would be the most intuitive, since most TS-hackers also have to deal with PHP anyway. But we should also consider at the same time to replace comma separated lists like those (which ought to be expanded in ext-templates) with "arrays", which is what this topic is about.

Apart from the config/page.config merging issue (which can be solved), I see no reason not to allow an array unter linkVars, which can be extracted in pagegen::pagegenInit().

New patch, see link for description:
http://lists.netfielders.de/pipermail/typo3-team-core/2006-February/001897.html

to me it sounds like a good solution without side effects and without breking compatibility.

i doubt that it will be part of 4.0 am i right?

regards Martin

This has been implemented in 4.0. The syntax to use it is:

config.linkVars := addToList(L,myparameter)