From: "John McNally" <[EMAIL PROTECTED]>
> >
> > 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.
The contract is written in the Java Language Specification:
The general contract of toString is that it returns a string that
"textually represents" this object. The idea is to provide a concise
but informative representation that will be useful to a person reading
it.
Whilst not directly stated, I think it can be implied that toString() should
refrain from modifying the object, which after all goes beyond "textually
representing" the object.
> #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. 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
I don't disagree with what you are saying. It impacted me because I
found it necessary to extend TemplateLink to provide a unique
component to every URL produced (in order to get around a proxy
server that does not obey the correct page expiry HTTP headers).
The problem I had was that in order to do this I had to override
both toString() and getURI() thus:
private static final String NOCACHE = "nocacheid";
public String getURI()
{
super.addPathInfo(NOCACHE, new java.util.Date().getTime());
String result = super.getURI();
super.removePathInfo(NOCACHE);
return result;
}
public String toString()
{
super.addPathInfo(NOCACHE, new java.util.Date().getTime());
return super.toString();
}
Very messy.
I didn't look at how TemplateLink or a replacement tool might be
implemented because I have too many templates that depend on the
existing behaviour and assumed that this would also be the case for
the vast majority of others.
Cheers,
Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
