After reading everybody's comments, and playing with things myself. I've
switched from using the getURI() and started using toString() to store the
link in a String object #set($persistentLink = $#set($xuseAction =
$link.setPage('Login.vm').setAction('MyAction').toString()).
I came to this decision, after experiencing first-hand, a problem where I
was using getURI() and then using the $link tool somewhere else in the
template. I ended up concatenating the new path and query info onto the
previous link, instead of starting with a fresh one. This was unexpected,
and could easily produce undesirable results.
thanks again,
scott
-----Original Message-----
From: John McNally [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 19, 2001 7:29 PM
To: Turbine Users List
Subject: Re: Issues with truncation of $link (TemplateLink) within
Velocity
I do not like the getURI method. I do not see the need for it. And i
do not think it fits in with a designer mindset. I am not sure of its
advantage over just calling toString()
If you plan to use the same url string call the toString() explicitly in
a #set directive. I guess it can allow you to not use a #set
<a href="$link.addQueryData("a", "b").getURI()">B</a>
...
<a href="$link.getURI()">B</a>
and avoid having to call addQueryData in the second link, but you cannot
modify the link in between the two calls. It can also be used in the
case where a later link contains everything the earlier link does but
adds new data. But this is a fragile arrangement. If its one
parameter, just repeat it and use the implied toString() call, if it is
several parameters or is something that is always added modify the tool
to make it more convenient, as you did.
john mcnally
Scott Eade wrote:
>
> 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]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
