[
https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639007#action_12639007
]
Geoff Callender commented on TAP5-264:
--------------------------------------
I question the use of the activation context for filter criteria.
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.
However, there's a persuasive argument for treating filter criteria differently
- ie. putting them into the query string portion of the URL instead of in the
context. that argument is made here:
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
Yes, it's not that hard to build our own links, eg:
@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");
}
But 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.
For actual resource-style URLs (which is what REST is all about) it would be
nice if we could simply turn on name/value/name/value URLs built automatically
by Tapestry, but is it really necessary unless Tapestry is going to do the
whole REST thing and handle PUT and DELETE operations. That should be a
different issue.
> Lack of direct support for named context parameters
> ---------------------------------------------------
>
> Key: TAP5-264
> URL: https://issues.apache.org/jira/browse/TAP5-264
> Project: Tapestry 5
> Issue Type: Improvement
> Affects Versions: 5.0.16
> Reporter: Francois Armand
>
> T5 "REST" orientation make easy the mappin between url and resources, but it
> lack the possibility to add "normal" named parameters.
> This one are quite handy when one's want to make big queries bookmarkable.
> For example, in a application that send email to dynamic mailing list build
> as the result of a search in the company user base, it would be great if each
> user can bookmark his most used filter/dynamic ml.
> The implementation can fit quite well with the current T5 implementation if
> we add a direct mapping of the kind :
> In URL map=[string=string,string=string] becomes a Map<String,String> in
> onActivate. I think that we can limit the use of Map<String,String> (at least
> for 5.0).
> For example :
> http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
> => in the Java code :
> void onActivate(String normalcontext, Map<String,String> mycontextmap, String
> othercontextparam) {
> String username = normalcontext:
> String telephone = mycontextmap.get("key1"); //let the user handle the type
> String email=mycontextmap.get("key2");
> String eqalityType=othercontextparam;
> ....
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
