On Wednesday, December 19, 2001, at 10:16 pm, John McNally wrote:
>> >> Yep, it is wrong because TemplateLink breaks the toString() >> contract by >> altering the value of the object. I as really annoyed when I >> found this, >> but >> I think it will be pretty difficult to fix it now short of >> implementing a >> completely new tool and migrating across to it manually. > > Where is this contract written? TemplateLink is written so that it can > be used multiple times within a template, with convenient syntax. If > you want to use a link generated by it in multiple places make sure to > call toString() in your #set. > > #set ($savedLink = $link.add(whatever).toString()) > > The other way to write a similar tool which does not reset by calling > the toString() would require something like: > > <a href="$link.add(stuff)">... > $link.reset() > <a href="$link.add(different_stuff)">.... > $link.reset() > > this is prone to error by designers. Maybe you have a better idea? It > is not difficult to change the tool. Very simple. This is because $link.add(xxx) modifies the link object. Just have it return a new object and you won't have this lame problem. If you need the modified link later, just use a #set: #set($link = $link.add(xxx)) This way $link will always render the same in the template. -- Denis. > Using an extended version of > TemplateLink would be a common thing to do, I would expect. There will > likely be convenience/shorthand methods to add common query data > or path > info that is specific to a particular application. I just had to write > one that includes virtual host info. Just plug in your preferred class > in TR.props. > > john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
