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]
