You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Francois Armand (JIRA)" <ji...@apache.org> on 2008/10/13 11:30:46 UTC
[jira] Created: (TAP5-264) Lack of direct support for named context
parameters
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Created: (TAP5-264) Lack of direct support for named
context parameters
Posted by Geoff Callender <ge...@mac.com>.
Absolutely - just go to the issue and click on Comment. If you can't
log in it's no problem to create an account.
On 13/10/2008, at 8:45 PM, Joel Halbert wrote:
> Would it be possible to add a comment to this request along the
> lines of:
>
> "Can we investigate using the @Persist("client") notation as a way
> of transparently storing named parameters across sessions, much in
> the same way as is done now, but with human friendly query string
> encodings for primitive types"
>
> Such that if one declares
>
> @Persist("client")
> String name;
>
> then rather than it being encoded on to the query string as
> "asjklnckjsndc09dc09j23oirnm3lknmsdcm.smdc" (etc .... !)
> it is simply encoded as "name=value" (or some similar variant, where
> ideally the encoding strategy can be user defined)
>
> I hope this makes sense...!?
>
> (I would add the comment myself but I believe only developers can do
> this?)
>
> Thx,
> Joel
>
>
>
> Francois Armand (JIRA) wrote:
>> 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;
>> ....
>> }
>>
>>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Created: (TAP5-264) Lack of direct support for named context
parameters
Posted by Joel Halbert <jo...@su3analytics.com>.
done, thx.
Francois Armand wrote:
> Joel Halbert wrote:
>> [...]
>> (I would add the comment myself but I believe only developers can do
>> this?)
> Absolutely not :) It's the beauty of opensource: just get an account
> on the apache's jira here:
> https://issues.apache.org/jira/secure/Signup!default.jspa , and post
> your comment. I'm in no way implied in the T5 development, I only use
> it (with delight, it's true ;)
>
> If you have a pb with that, I will post your comment, but I believe
> it's better if you record your own comment :)
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Created: (TAP5-264) Lack of direct support for named context
parameters
Posted by Francois Armand <fa...@linagora.com>.
Joel Halbert wrote:
> [...]
> (I would add the comment myself but I believe only developers can do
> this?)
Absolutely not :) It's the beauty of opensource: just get an account on
the apache's jira here:
https://issues.apache.org/jira/secure/Signup!default.jspa , and post
your comment. I'm in no way implied in the T5 development, I only use it
(with delight, it's true ;)
If you have a pb with that, I will post your comment, but I believe it's
better if you record your own comment :)
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Created: (TAP5-264) Lack of direct support for named context
parameters
Posted by Joel Halbert <jo...@su3analytics.com>.
Would it be possible to add a comment to this request along the lines of:
"Can we investigate using the @Persist("client") notation as a way of
transparently storing named parameters across sessions, much in the same
way as is done now, but with human friendly query string encodings for
primitive types"
Such that if one declares
@Persist("client")
String name;
then rather than it being encoded on to the query string as
"asjklnckjsndc09dc09j23oirnm3lknmsdcm.smdc" (etc .... !)
it is simply encoded as "name=value" (or some similar variant, where
ideally the encoding strategy can be user defined)
I hope this makes sense...!?
(I would add the comment myself but I believe only developers can do this?)
Thx,
Joel
Francois Armand (JIRA) wrote:
> 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;
> ....
> }
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Ivan Dubrov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639014#action_12639014 ]
Ivan Dubrov commented on TAP5-264:
----------------------------------
I think, the Persist is global-wide whereas query parameters are local to page. They have different meaning.
For example, I can have two pages with @Persist("client") private int page; and they both can have different value at the same time. I would be very surprised if changing page on one page will change it on other page (so they should not be stored in same parameter "page=<value>"). Also, @Persist means that value is not lost while navigating, so it is generally more long-lived when regular query parameters.
So, I don't think it is good idea to use @Persist mechanism for query parameters.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Joel Halbert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639012#action_12639012 ]
Joel Halbert commented on TAP5-264:
-----------------------------------
I would agree with Geoff & Ivan comments that using the activation context is probably not the right way forward and that use of annotations would be a more elegant solution.
I would advocate that, although the default encoding used should of course be sensible (e.g. a=b?c=d etc...), the user should ultimately be able to define their own encoding scheme by overriding the default.
Also - any thoughts on modifying the current @Persist("client") behaviour to achieve some of these goals?
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Joel Halbert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639000#action_12639000 ]
Joel Halbert commented on TAP5-264:
-----------------------------------
Could we investigate using the @Persist("client") notation as a way of transparently storing named parameters across sessions, much in the same way as is done now, but with human friendly query string encodings for primitive types
Such that if one declares
@Persist("client")
String name;
then rather than it being encoded on to the query string as "asjklnckjsndc09dc09j23oirnm3lknmsdcm.smdc"
it is simply encoded as "name=value" (or some similar variant, where ideally the encoding strategy can be user defined)
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Francois Armand (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639004#action_12639004 ]
Francois Armand commented on TAP5-264:
--------------------------------------
@Massimo Lusetti : well, there is two paradigm that cohabits. You may want that some part of your application are RESTfull, but you may have to build some big, heavy, client dependent wizards, and here persist/hidden field might be the way to go.
That one of the things I really like in T5 : by default, simple things just work, but if we want to do strange and really non standard things, it gives us the tools to do as we want, extends the framework, etc.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638998#action_12638998 ]
Massimo Lusetti commented on TAP5-264:
--------------------------------------
Talking about the T5 "REST" orientation... how would you consider the presence of T5 hidden formdata field within forms?
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Joel Halbert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639002#action_12639002 ]
Joel Halbert commented on TAP5-264:
-----------------------------------
Regarding Massimo's comment : "Talking about the T5 "REST" orientation... how would you consider the presence of T5 hidden formdata field within forms?"
My Comment: From an end users perspective it might would be ideal if named parameters (whether from hidden fields, or url encoded) could be handled on the server side (i.e. retrieved and accessed) in the same way - i.e. the difference between url encoded and hidden fields on the server side was mostly transparent.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Geoff Callender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639016#action_12639016 ]
Geoff Callender commented on TAP5-264:
--------------------------------------
If not @Persist("client"), then perhaps @Persist("query") or @QueryParameter
Ideally you could specify a name to override the field name, eg.
@QueryParameter(strategy = query, name = asc)
private boolean ascending;
giving a URL ending with "?asc=true"
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Issue Comment Edited: (TAP5-264) Lack of direct support for
named context parameters
Posted by "Geoff Callender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639016#action_12639016 ]
geoffcallender edited comment on TAP5-264 at 10/13/08 3:39 AM:
----------------------------------------------------------------
If not @Persist("client"), then perhaps @Persist("query") or @QueryParameter
Ideally you could specify a name to override the field name, eg.
@QueryParameter(name = asc)
private boolean ascending;
giving a URL ending with "?asc=true"
was (Author: geoffcallender):
If not @Persist("client"), then perhaps @Persist("query") or @QueryParameter
Ideally you could specify a name to override the field name, eg.
@QueryParameter(strategy = query, name = asc)
private boolean ascending;
giving a URL ending with "?asc=true"
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Ivan Dubrov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639009#action_12639009 ]
Ivan Dubrov commented on TAP5-264:
----------------------------------
I vote for something similar to activation parameters, but with names. So you have field @QueryParameter int page; and it is added to URL as ?page=<value>. Also, createPageLink/createEventLink/etc should have possibility to override named parameters as well as regular page context parameters (by providing map of overrides or something like this).
The idea is illustrated here: http://www.nabble.com/Re%3A-%22named%22-page-context-parameters---p19893835.html
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-264) Lack of direct support for named
context parameters
Posted by "Geoff Callender (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org