Rob van Maris wrote: > Just to be sure, how do I replace this call in a tag that inherits from > CloudReferrerTag: > getContextTag().register(newId, n) > > Should this be: > getContextProvider().getContextContainer().register(newId, n) > > Or, as the apidoc suggests: > getContextTag().getContextProvider().getContextContainer().register(newI > d, n)
The first one. The apidoc does indeed not explicitely state in place of what you must use this. For absolute backwards-compatibily without deprecation warnings you could replace with: getContextTag().getContextContainer().register(newId, n); But I don't think that is advicable. Because 1.7 there are more context-provider then just context-tag. Also all list tags are now context-providers (though their context is more or less 'transparent'). The idea is that people didn't understand and/or found it cumbersome that they should explicitly use a <mm:context in the body of the list or remove variables in the beginning of the body, to avoid this 'already defined' error. This is not needed anymore if the tags in the body use getContextContainer in stead of getContextTag, because that will hit the lists too, which will propagate the contents to _their's_ getContextProvider when it's ready (so that everything remained backwards compatible, but without those kind of errors). Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
