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.
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]
