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
