Geoff Callender wrote: > Hi Joel, > > The activation context is great for passing object ids (or entity > ids), and with database backed applications that is exactly what you'd > be doing most of the time. The notion behind REST is that each URL > represents a resource, which is pretty much what ids represent too. > > I agree that it would be good to be able to turn on > name/value/name/value URLs built automatically by Tapestry, but only > for resource-style URLs (which is what REST is all about). > > Filter criteria, however, I think deserve different treatment, ie.they > should be added as a query string. I thoroughly agree that it would > be good if T5 provided a formalised way of handling this difference > that didn't involve us building our own Links. I think, they basically could be handled the same way as regular activation context. There could be two event methods, Map<String, Object> onPassivateParameters()/onActivateParameters(Map<String, Object> params) with similar meaning to onActivate and onPassivate. Also, there could be an annotation @QueryParameter, which will work the same way as @PageActivationContext.
I’ve already implemented something similar, I described the idea here: http://www.nabble.com/Re%3A-%22named%22-page-context-parameters---p19893835.html Hovewer, this solution is limited in several aspects. First of all, you cannot override the parameters the same way you can override the activation context in the resources.create*Link() calls. That makes generating the links a bit more cumbersome (you have to save old value of field marked by @QueryParameter, then set value you need, then generate link and finally restore the previous field value). Secondly, the framework does not allows specifying empty parameter values. For example, I want “/orders” to works the same as “/orders?status=NEW” and “/orders?status=” to show all orders (not only new). And finally, Tapestry does not allow having multiple parameters with same name (for example, “/orders&status=NEW&status=REJECTED”, which is correct URL). > > BTW, the current options are on demonstration at > http://202.177.217.122:8080/jumpstart/examples/state/passingdatabetweenpages1 > > > Cheers, > > Geoff > > On 13/10/2008, at 12:08 AM, Joel Halbert wrote: > >> I'm a new T5 user so wasn't familiar with the pattern below for >> adding params to links, I'll definitely try it out. >> >> However, If you go down the route you suggest below for passing >> parameters between page, then what is the true value in the >> activation context in the first place other than for the most simple >> of requirements - (given that it seems unwieldy for large numbers of >> parameters) ? >> >> Additionally, I would suggest that *how* activation context >> parameters are encoded onto the URL should be configurable, so you >> could choose to encode your activation parameters like this a/b/c/d >> or like this a=b&c=d , or any other encoding mechanism you want. >> >> I really want to like the T5 framework, and in my limited experience >> (4 days!) I think I do, especially because it seems much leaner and >> more scalable than say Wicket, something I have used more extensively >> and which because of its component based nature, and lack of page >> pooling, creates and enormous amount of objects per page request >> which then need to be cleaned up - a bit wasteful if you are only >> creating stateless pages. >> However I was quite suprised by what that I saw as a gap in native >> (out the box & convenient & maintainable) support for truly stateless >> pages in T5. As a stop gap I have got round the problem by writing a >> custom ValueEncoder to encode and decode HashMap objects onto the >> activation context, as a string like this key1_value1_key2_value2 >> etc, that way I work within the framework but with full support for >> named parameters. >> >> I think the ideal solution (for an end user at least!) would be to >> make it such that the @Persist("client") notation did all the hard >> work of encoding primitive params on to a query sting, but more >> concisely that it currently does >> >> i.e. what cann't a primitive variable such as >> >> @Persist("client") >> private String name; >> >> be simply encoded onto the url as "name=value" rather than the >> current solution of an enourmously long encoded value? >> If this were to happen then I think T5 really would be a truly great >> framework! >> >> Thx, >> Joel >> >> >> Geoff Callender wrote: >>> I'm not keen on the named context parameters idea. There's a >>> persuasive argument for putting filter parameters into the query >>> string portion of the URL instead of in the context. >>> http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/ >>> >>> >>> So you get a URL like this >>> http://localhost:8080/myapp/mypage?firstname=Humpty&lastname=Dumpty >>> instead of this >>> http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty >>> >>> It's easy enough to do: >>> @Inject >>> private ComponentResources _componentResources; >>> >>> @Inject >>> private Request _request; >>> >>> public Link set(String firstName, String lastName) { >>> Link link = >>> _componentResources.createPageLink(this.getClass(), true); >>> >>> if (firstName != null) { >>> link.addParameter("firstname", firstName); >>> } >>> if (lastName != null) { >>> link.addParameter("lastname", lastName); >>> } >>> return link; >>> } >>> >>> void onActivate() { >>> _firstName = _request.getParameter("firstname"); >>> _lastName = _request.getParameter("lastname"); >>> } >>> >>> On 11/10/2008, at 12:37 AM, Joel Halbert wrote: >>> >>>> I tend to try and keep all my pages as stateless as possible, you >>>> can then quite easily require a few query string parameters per >>>> page when this is the case, consider the case of browsing a >>>> storefront - you need a "category id" (e.g. books, shoes), a page >>>> number (for the current page if looking at paginated data) and a >>>> "sort by" field (for the clients sort by selection). Already we >>>> have 3. There can easily be more, say if the client is "filtering" >>>> the view. >>>> >>>> Thiago H. de Paula Figueiredo wrote: >>>>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert >>>>> <[EMAIL PROTECTED]> escreveu: >>>>> >>>>>> I was wondering whether anyone missed the lack of direct support >>>>>> for named context parameters? >>>>>> I try to keep my pages as stateless as possible (thus >>>>>> bookmarkable) and better support for "named" context variables >>>>>> would make this much easier. >>>>> >>>>> I haven't missed named context parameters because my pages, almost >>>>> all the time, need just one parameter, sometimes two, so there is >>>>> no need to name them. >>>>> >>>> >>>> -- >>>> SU3 Analytics Ltd >>>> 61b Oxford Gardens >>>> W10 5UJ >>>> London >>>> >>>> Tel: +44 20 8960 2634 >>>> Mob: +44 75 2501 0825 >>>> www.su3analytics.com >>>> >>>> SU3 Analytics Ltd is a company registered in England and Wales >>>> under company number 06639473 at registered address 61b Oxford >>>> Gardens, London W10 5UJ, United Kingdom. >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> >> >> -- >> SU3 Analytics Ltd >> 61b Oxford Gardens >> W10 5UJ >> London >> >> Tel: +44 20 8960 2634 >> Mob: +44 75 2501 0825 >> www.su3analytics.com >> >> SU3 Analytics Ltd is a company registered in England and Wales under >> company number 06639473 at registered address 61b Oxford Gardens, >> London W10 5UJ, United Kingdom. >> >> >> >> --------------------------------------------------------------------- >> 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] > > -- WBR, Ivan S. Dubrov --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
