There was a jira feature request raised for named params some time ago:
https://issues.apache.org/jira/browse/TAP5-264
Andy - in the meantime, another alternative is to create a custom
ValueEncoder for activation contexts which can encode and decode a map.
You could then encode the map context using a scheme which uses, for
example, underscores as delimiters, such as:
/mypage/name1_value1_name2_value2
(i.e. /mypage/<context>)
This would allow you to access params by name from an activation
context.
This works well enough so long as you do not care about using the
correct http request syntax for query strings
(?name1=value1&name2=value2).
-----Original Message-----
From: Carl Crowder <carl.crow...@taptu.com>
Reply-To: Tapestry users <users@tapestry.apache.org>
To: Tapestry users <users@tapestry.apache.org>
Subject: Re: T5: Passing named/structured-type params in URLs?
Date: Sat, 09 May 2009 12:05:28 +0100
I did actually try writing something like this a while ago. The problem
is that you need to specify more than just the name of the parameter,
you need to know which component it's part of.
I ended up with urls like:
/page?component1.component2.param=<somevalue>&component1.component3.param2=<somevalue>
So as you can see, they quickly become very large.
You could mandate that only top-level components (ie, pages) can use
that persistence strategy, but that seems to be counter-intuitive.
I toyed with the idea of mapping those names to some smaller IDs - a
service which simply converts "p1" to "component1.component2.param" so
you could have urls looking like:
/page?p1=<somevalue>&p2=<somevalue>
The problem then is it's hard to work out what the params actually are
for the user/developer. Also, how do you populate that map to start
with? You'd have to load each page and component class at startup.
I didn't ever finish this code as I worked out how to do what I wanted
with vanilla PageActicationContext in the end.
Robert Zeigler wrote:
> That should work.
> I think it could be interesting, though, if tapestry provided an
> additional persistence mechanism, ala:
>
> @Persist(PersistenceConstants.QUERY_PARAMETER)
> private String p;
>
> @Persist(PersistenceConstants.QUERY_PARAMETR)
> private Integer irn;
>
> which would then take the values in p and irn and stash them in the url,
> like:
> p=<valueEncodedValue>&irn=<valueEncodedValue>
>
> Obviously this wouldn't be appropriate to use everywhere; if you're
> concerned about users tampering with URLs, you'd want to avoid it.
> But in cases like that presented below, where you expressly want users
> to be able to muck about with parameters, it would be useful.
>
> Note that this is similar to the current client-side persistence
> mechanism, except that mechanism a) rolls all persisted values into a
> single parameter and b) base64 encodes the parameter.
>
> As long as you've got the basic mechanism for doing the above, you could
> translate it into a "pretty" url via url rewriting without too much
> trouble.
>
> Thoughts?
>
> Robert
>
> On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
>
>> Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
>> <andy.buck...@durham.ac.uk> escreveu:
>>
>>> So, is there a Tapestry meachnism for doing something like this? I
>>> can do it right now, but I'd rather not have to fight the system. I
>>> would expect Tapestry to do it a bit prettier than what I've shown,
>>> maybe *something* like
>>> .../view/irn/12349876/d/1,2,4
>>> (yes, there are issues with telling what's a param name and what's a
>>> value... I just mean this schematically) But right now I don't even
>>> know where to start looking! Help, please!? ;)
>>
>> Just use a List as the activation context value. For each named
>> parameter one want, add the name first, the value second.
>> The above URL would be constructed by Tapestry if you returned a List
>> populated like this:
>>
>> List list = new ArrayList();
>> list.add("irn");
>> list.add(1245569);
>> list.add("d");
>> list.add("1,2,4");
>>
>> Then, declare a onActivate(EventContext context) method and
>> reconstruct the pairs:
>>
>> for (int i = 0; i < context.getCount() / 2; i++) {
>> String name = context.get(String.class, i * 2);
>> String value = context.get(String.class, i * 2 + 1) // instead of
>> String, you could use any type here
>> }
>>
>> I have not tested this code, but I guess you get the idea. ;)
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
