Sorry one typo: eventContext.get(Integer.class, i) needs to be a String in this example.
----- Original Message ----- From: "Peter Stavrinides" <[email protected]> To: "Tapestry users" <[email protected]> Sent: Wednesday, 13 May, 2009 17:22:59 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: T5: Passing named/structured-type params in URLs? This is an interesting thread, and a way overdue discussion... it has given me some nice ideas, so let me also share one of mine. > you sometimes need the flexibility offered by request parameters - and that > is currently way too hard (compared to how easy most things are) in > Tapestry. Yes, I drew the same conclusion after experiencing similar problems... At first I thought of messing with the URL, but opted out of that because and I like the clean URL's Tapestry produces and didn't want to mess them up. Since 'request parameters' are simply stored as a key value pair, i.e.: a map, I figured you could use reflection and reconstruct them as named parameters with the help of an Annotation. So I implemented a BasePage with the EventContext interface and then populated a LinkedHashMap, something like this: In any given page class: @ContextVariables(variables = { ContextVariables.DOCUMENT , ContextVariables.COMPANY, ...}) ... The base page: protected Object onActivate(EventContext eventContext) { String[] context = null; //Extract annotated variables from the class if (getClass().isAnnotationPresent(ContextVariables.class)) { ContextVariables annotation = getClass().getAnnotation( ContextVariables.class); context = annotation.variables(); _namedContext = new LinkedHashMap<String, String>(); // iterate over context variables for (int i = 0; i < eventContext.getCount(); i++) { // a type check and add if (context[i].equals(ContextVariables.DOCUMENT)) { _namedContext.put(ContextVariables.DOCUMENT, eventContext.get(Integer.class, i)); } //more names params etc... } } return null; } So I think its fairly clean and flexible solution. Kind regards, Peter ----- Original Message ----- From: "Filip S. Adamsen" <[email protected]> To: "Tapestry users" <[email protected]> Sent: Wednesday, 13 May, 2009 16:19:17 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: T5: Passing named/structured-type params in URLs? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wanted something like this maybe nine months ago and ended up creating my own @RequestParameter annotation, overriding Form, ActionLink, EventLink, and PageLink, and modifying the way Tapestry generates URLs. It works, but it ain't pretty. Anyway, back then, it looked like something like this would be easy enough to implement using a persistence strategy, it would just require some changes to many aspects of URL handling in Tapestry - for one, I remember needing access to the name of the page a Link was for. I think that it would be worthwhile, though - the activation context is great for a lot of things, but as you can tell from this thread, you sometimes need the flexibility offered by request parameters - and that is currently way too hard (compared to how easy most things are) in Tapestry. /Filip On 2009-05-09 00:29, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKCsjVAAoJEEfiH7PpjaMnWbIIAJdAPuQo5jngCCZt2DSXV5e3 dGG+0wOOnxrmC2jFTDrxVRvWx7dfA4hGuAFPQgz/USP+NviNkEvFz2iGfZTAgmzA 19BFLfx1AdWYu2ft1tPULkBGmxaLa/Rjt0qosHn3+kKo+Kgl0yhDjcZSbx29+Ic6 8eBRn0krOha5o6GU6OU/iIqMEjRvErAOutB63nlRr7oIfuttffucPXDGE0UutQ9v llwzlQoGfk5ywHr0AqJlclA0AH44ePOtxiP4xg3OwgVh9Wge/vHMVGxYURzbp/lf wvqTP3iASZHOYEYpji6/J31awC/3T8gcP+Rm/53VLrDtsU2dHnfzJ+B7hJpjYAk= =SYe3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
