Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote: Em Mon, 18 May 2009 13:31:43 -0300, Andy Buckley andy.buck...@durham.ac.uk escreveu: One final, final (I hope) thing: the decoded context appears to be shared between pages using the same session, They aren't. Maybe you're populating persisted fields . . . private MapString,String _params = new TreeMap(); . . . or falling in the initialized page fields trap. :) *Never* initialize page or component fields in their declaration, as Tapestry pools page and instance objects and their initial values are restored when an instance is used for another request. Thanks, that sorted it. Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote:
Em Fri, 15 May 2009 12:36:34 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
Any replies to this (see below, or my previous mail in this thread)?
Specifically, can I use Tapestry components to link bookmarkably to
page events as a way of displaying the page in alternative formats
(inc. different MIME types)? And if this is an abuse of the events
system, what alternative approach do you recommend for (extensible)
alternative page formats?
Component events, IMHO, are abused to do what you wrote. On the other
hand, you can use page events (onActivate) to do this. Don't forget that
you can return a StreamResponse in onActivate() or any other event
handler method. ;) The URL would be something like
/page/parametername1/value1/parametername2/value2/format/pdf. Another
approach would be another page for another response format.
Thanks for the advice. I'd rather avoid using separate pages, as
mentioned, but including the format handling in the activation context
is certainly possible. It prompts another question, though: how do I
return the normal page rendering as a StreamResponse in onActivate?
Here's the outline of my new onActivate() method:
public StreamResponse onActivate(EventContext context) {
[interpret context]
...
// Handle special format returns
String fmt = getQueryParam(format);
if (fmt.equals(plain)) {
return asPlain();
}
// Normal rendering
return null; // this is wrong!
}
That return null is obviously wrong: I was hoping that it would fall
back to the default page rendering via the template but it just causes a
NullPointerException. How can I return the default rendering in this way?
Thanks!
Andy
--
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote: Em Fri, 15 May 2009 14:39:23 -0300, Robert Zeigler robe...@scazdl.org escreveu: PS: I don't see EventContext implementing IterableString. It just doesn't make sense from a semantic POV, even it makes things a bit more convenient. It's also a public interface; it's not going to change anytime soon. :) One more reason: EventContext.get() does conversion (through TypeCoercer) from the parameter value (a String) to any type that has a String - type conversion, so limiting it to be an iterable of Strings does not make much sense. :) I noticed that, but reckoned that if Iterable was to be implemented for any particular type, String is the most fundamental: the type coercion could always be applied on the string in the loop if wanted. But it's no biggie, just an expression that I find it rather unusual to have to use explicit loop indices in Java these days when essentially performing a foreach operation ;) Cheers, Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
On Mon, May 18, 2009 at 10:57 AM, Andy Buckley andy.buck...@durham.ac.uk wrote: Thanks for the advice. I'd rather avoid using separate pages, as mentioned, but including the format handling in the activation context is certainly possible. It prompts another question, though: how do I return the normal page rendering as a StreamResponse in onActivate? Return null. That return null is obviously wrong: I was hoping that it would fall back to the default page rendering via the template but it just causes a NullPointerException. Please post the stack trace, as returning null is the way to do what you want. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Robert Zeigler wrote:
1) If you're using action links, then
onXML won't work. The proper magic method naming is:
oneventname[fromcomponentname]
as:
onActionFromXml, and so forth.
If you want:
onXML() {} then you need to use an event link with the event name of xml.
Thanks, I hadn't noticed EventLink until now!
I'm not /quite/ sure what you mean by doesn't pass the parameters as
expected.
As in, the page context params do not appear in the
ActionLink-generated URI. I still see this with an EventLink; on a page
with URI
.../view/p1234
an EventLink like this
a href=# t:type=eventlink t:event=xmlXML/a
generates a link with this URI:
.../view:xml
i.e. the context of the page containing the link is not propagated to
the URI of the event link. Is this expected? From your discussion of the
two contexts (below), I would expect the page activation context to be
merged with the link context (which I'm not specifying).
There are two different contexts at play when you're using an event
link or an action link: the link context, and the page's activation
context. In an action link, at least, the page's activation context
winds up in a query parameter like: t:ac=contextvalues. Then the
context from the action or event link is also used, and /these/ values
are what are passed to the event handler method. So as long as your
onPassivate correctly returns the current activation context state,
then your onActivate handler should be called for event and action
links, and then the only issue left is to handle your events however you
want to handle them.
I wasn't explicitly implementing onPassivate(). Interpreting what you
say above, if I add
public EventContext onPassivate(EventContext context) {
return context;
}
then I get an EventLink URI like this:
.../view:xml?t:ac=org.apache.tapestry5.internal.structure.ComponentPageElementImpl$$14$004075ecf6
Bookmarkable, but not something that can be programmatically accessed...
and it shows a bit too much of the servlet internals for my taste!
Andy
--
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
On Mon, May 18, 2009 at 11:19 AM, Andy Buckley
andy.buck...@durham.ac.uk wrote:
public EventContext onPassivate(EventContext context) {
return context;
}
In onPassivate(), you should return the activation context value for
that page request (i.e. the value you pass to the context parameter of
PageLink). In your case, it will be a List or Map and could be a
String or Integer, for example,, but not an EventContext.
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote: On Mon, May 18, 2009 at 10:57 AM, Andy Buckley andy.buck...@durham.ac.uk wrote: Thanks for the advice. I'd rather avoid using separate pages, as mentioned, but including the format handling in the activation context is certainly possible. It prompts another question, though: how do I return the normal page rendering as a StreamResponse in onActivate? Return null. That return null is obviously wrong: I was hoping that it would fall back to the default page rendering via the template but it just causes a NullPointerException. Please post the stack trace, as returning null is the way to do what you want. Thanks for the help and rapid response; much appreciated! Prodding me to take a proper look at the stack trace was just what was needed: the NullPointerException was in my testing for the format param rather than in Tapestry's handling of the null return! So I now have a working multi-format onActivate(). Cool! One last question, how to link to these alternative formats? I've tried a PageLink in View.tml: a href=# t:type=pagelink t:page=view t:context=literal:xmlXML/a but as mentioned elsewhere in the thread, this generates a URI without the parent page's context (which magically still works), i.e. the URI generated by the above is .../view/xml rather than the hoped-for .../view/p1234/xml Can you help with this last piece of the jigsaw? ;) Thanks yet again; I've learned a lot about Tapestry thanks to your (pl) helpful replies. Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
On Mon, May 18, 2009 at 11:48 AM, Andy Buckley
andy.buck...@durham.ac.uk wrote:
a href=# t:type=pagelink t:page=view t:context=literal:xmlXML/a
but as mentioned elsewhere in the thread, this generates a URI without
the parent page's context (which magically still works), i.e. the URI
generated by the above is
.../view/xml
rather than the hoped-for
.../view/p1234/xml
You'll need to pass the full context (normal parameters + format parameter):
a ... t:context=xmlContext
public Object getXmlContext() {
List list = new ArrayList(); // or Map
list.add(parameter1);
list.add(parameter2);
list.add(xml);;
}
Of course, as you have the same proper context (without format
parameter) in more than one method, you'll refactor the above method.
Was the example good?
Can you help with this last piece of the jigsaw? ;) Thanks yet again;
I've learned a lot about Tapestry thanks to your (pl) helpful replies.
We all learn a lot from each other in this list. :)
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote:
On Mon, May 18, 2009 at 11:48 AM, Andy Buckley
andy.buck...@durham.ac.uk wrote:
a href=# t:type=pagelink t:page=view t:context=literal:xmlXML/a
but as mentioned elsewhere in the thread, this generates a URI without
the parent page's context (which magically still works), i.e. the URI
generated by the above is
.../view/xml
rather than the hoped-for
.../view/p1234/xml
You'll need to pass the full context (normal parameters + format parameter):
a ... t:context=xmlContext
public Object getXmlContext() {
List list = new ArrayList(); // or Map
list.add(parameter1);
list.add(parameter2);
list.add(xml);;
}
Of course, as you have the same proper context (without format
parameter) in more than one method, you'll refactor the above method.
Was the example good?
Yes, that's great, thanks. It would be nice if inheriting the context
from the linking page in the link URI could be automated e.g.:
a ... t:inheritcontext=true t:context=literal:xml
especially since I want to be able to generate a lot of these context
links for the different dataset, x, y axis numbers. I've managed to hack
something for now which will do.
One final, final (I hope) thing: the decoded context appears to be
shared between pages using the same session, which I notice if I have
two browser tabs viewing different records. If I view one tab/page as a
single dataset, or in XML format (in each case, this corresponds to an
extra context parameter), then reloading the other will be rendered as
if that extra parameter was present. Any idea what would be causing this
and how to stop it? The parameter values are accessed via this map and
method:
private MapString,String _params = new TreeMap();
public String getQueryParam(String param) {
return _params.get(param);
}
Do I need to annotate these somehow to tell them to not be shared
between instances of the page?
Andy
--
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Em Mon, 18 May 2009 13:31:43 -0300, Andy Buckley andy.buck...@durham.ac.uk escreveu: One final, final (I hope) thing: the decoded context appears to be shared between pages using the same session, They aren't. Maybe you're populating persisted fields . . . private MapString,String _params = new TreeMap(); . . . or falling in the initialized page fields trap. :) *Never* initialize page or component fields in their declaration, as Tapestry pools page and instance objects and their initial values are restored when an instance is used for another request. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Any replies to this (see below, or my previous mail in this thread)?
Specifically, can I use Tapestry components to link bookmarkably to
page events as a way of displaying the page in alternative formats (inc.
different MIME types)? And if this is an abuse of the events system,
what alternative approach do you recommend for (extensible) alternative
page formats?
Cheers,
Andy
Andy Buckley wrote:
Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
So, is there a Tapestry meachnism for doing something like this? I can
do it right now, but I'd rather not have to fight the system. I would
expect Tapestry to do it a bit prettier than what I've shown, maybe
*something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's a
value... I just mean this schematically) But right now I don't even
know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a List
populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and reconstruct
the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
Thanks: I've opted to use something similar to this, but with regex
matching instead of twice as many directory levels as expected, e.g.
decoding URLs like
.../view/irn1245569/d1,2,4/x1
in the obvious way. Seems to work fairly well so far, so thanks for the
pointer.
This has sparked an extra question, though: I also want to be able to
render my data records in several different ways, i.e. nice HTML tables
by default, but also structured plain text, XML, plotting code and other
formats on demand. Like the main page, these should be accessible via
the URL. So far, I've been using event handlers, e.g.
.../view:xml?irn=1245569d=1
to call a View.onXML() method. In moving to this new regexy context
encoding, I tried using ActionLinks to make these alternative-format
links, but it doesn't pass the parameters as expected: I have to add an
@OnEvent(component=xml) annotation to the onXML() method for it to
work at all, and when I do that the ActionLink uses a dot in the URL
rather than a colon, and ignores the context. I assume there's some
session magic going on to make it work at all, but it means that the
alternative formats can't be accessed via URLs. If I explicitly build
the URL with the context used before, e.g.
.../view.xml/irn1245569/d1
then I get an exception. Is there a way that I can keep using event
handlers for alternative formats and still pass the context params in
the URL? I'd rather not have to split all these formats off into
separate pages, since each contains relatively little logic and the
context decoding seems best defined in the page class (not least for
class reloading convenience.) Looking forward to more useful answers ;)
By the way, T5 developers, it would be nice if the EventContext was
IterableString, so the old-style for-loop can be replaced with
something more Java 5+ish like for (String s : context) { ... for
those who just want strings back from the URL context. But that's a
minor, minor point! ;)
Thanks again,
Andy
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
1) If you're using action links, then
onXML won't work. The proper magic method naming is:
oneventname[fromcomponentname]
as:
onActionFromXml, and so forth.
If you want:
onXML() {} then you need to use an event link with the event name of
xml.
I'm not /quite/ sure what you mean by doesn't pass the parameters as
expected.
There are two different contexts at play when you're using an event
link or an action link: the link context, and the page's activation
context. In an action link, at least, the page's activation context
winds up in a query parameter like: t:ac=contextvalues. Then the
context from the action or event link is also used, and /these/ values
are what are passed to the event handler method. So as long as your
onPassivate correctly returns the current activation context state,
then your onActivate handler should be called for event and action
links, and then the only issue left is to handle your events however
you want to handle them.
Robert
PS: I don't see EventContext implementing IterableString. It just
doesn't make sense from a semantic POV, even it makes things a bit
more convenient. It's also a public interface; it's not going to
change anytime soon. :)
On May 15, 2009, at 5/1510:36 AM , Andy Buckley wrote:
Any replies to this (see below, or my previous mail in this thread)?
Specifically, can I use Tapestry components to link bookmarkably
to page events as a way of displaying the page in alternative
formats (inc. different MIME types)? And if this is an abuse of the
events system, what alternative approach do you recommend for
(extensible) alternative page formats?
Cheers,
Andy
Andy Buckley wrote:
This has sparked an extra question, though: I also want to be able to
render my data records in several different ways, i.e. nice HTML
tables
by default, but also structured plain text, XML, plotting code and
other
formats on demand. Like the main page, these should be accessible via
the URL. So far, I've been using event handlers, e.g.
.../view:xml?irn=1245569d=1
to call a View.onXML() method. In moving to this new regexy context
encoding, I tried using ActionLinks to make these alternative-format
links, but it doesn't pass the parameters as expected: I have to
add an
@OnEvent(component=xml) annotation to the onXML() method for it
to
work at all, and when I do that the ActionLink uses a dot in the URL
rather than a colon, and ignores the context. I assume there's some
session magic going on to make it work at all, but it means that the
alternative formats can't be accessed via URLs. If I explicitly build
the URL with the context used before, e.g.
.../view.xml/irn1245569/d1
then I get an exception. Is there a way that I can keep using event
handlers for alternative formats and still pass the context params in
the URL? I'd rather not have to split all these formats off into
separate pages, since each contains relatively little logic and the
context decoding seems best defined in the page class (not least for
class reloading convenience.) Looking forward to more useful
answers ;)
By the way, T5 developers, it would be nice if the EventContext was
IterableString, so the old-style for-loop can be replaced with
something more Java 5+ish like for (String s : context) { ... for
those who just want strings back from the URL context. But that's a
minor, minor point! ;)
Thanks again,
Andy
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Em Fri, 15 May 2009 12:36:34 -0300, Andy Buckley andy.buck...@durham.ac.uk escreveu: Any replies to this (see below, or my previous mail in this thread)? Specifically, can I use Tapestry components to link bookmarkably to page events as a way of displaying the page in alternative formats (inc. different MIME types)? And if this is an abuse of the events system, what alternative approach do you recommend for (extensible) alternative page formats? Component events, IMHO, are abused to do what you wrote. On the other hand, you can use page events (onActivate) to do this. Don't forget that you can return a StreamResponse in onActivate() or any other event handler method. ;) The URL would be something like /page/parametername1/value1/parametername2/value2/format/pdf. Another approach would be another page for another response format. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Em Fri, 15 May 2009 14:39:23 -0300, Robert Zeigler robe...@scazdl.org escreveu: PS: I don't see EventContext implementing IterableString. It just doesn't make sense from a semantic POV, even it makes things a bit more convenient. It's also a public interface; it's not going to change anytime soon. :) One more reason: EventContext.get() does conversion (through TypeCoercer) from the parameter value (a String) to any type that has a String - type conversion, so limiting it to be an iterable of Strings does not make much sense. :) -- Thiago H. de Paula Figueiredo Consultor, desenvolvedor e instrutor em Java http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: T5: Passing named/structured-type params in URLs?
I've been following this thread with interest and have a somewhat different requirement. I have a desire to use a context where the delimeter for one of the values is itself a '/'. For example: /docs/my/path/to/doc/document1/param1/param2 I can do this by hand in a page by having onActivate(EventContext ctx) and iterating the elements of the path. However, what if param2 is optional? Also, it means I have to do this work manually on every page. I realise that to make this work more generally I'd need to have another kind of separator in there, eg: /docs/my/path/to/doc/document1/-/param1/param2 I'd might then have a signature like: void onActivate(DocPath path, Object param1, Object param2) and have the T5 machinery encode/decode urls accordingly. Is this possible or am I asking too much? This is all in a drive to having nice looking URLs... A simpler alternative might be to simply use a different context value separater, eg. '-' for apps where the context values are themselves meaningful paths. Is this possible? This would lead to a url like: /docs/my/path/to/doc/document1-param1-param2 Which kind of works for me. Thanks! Alfie. -Original Message- From: Joel Halbert [mailto:j...@su3analytics.com] Sent: 12 May 2009 17:51 To: Tapestry users Subject: Re: T5: Passing named/structured-type params in URLs? Hi Andy, The same Encoder could indeed be used across multiple pages. Some pointers: You need to create one of these: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/ValueEncoder.html Look at the source for one of the existing implementation for ideas, e.g. StringEncoder [snip]
RE: T5: Passing named/structured-type params in URLs?
I have a desire to use a context where the delimeter for one of the values is itself a '/'. For example: /docs/my/path/to/doc/document1/param1/param2 Do you mean that one of the parameters is the value document/, if so will T5 not URL encode this to the value document%2F ? (although StringValueEncoder, v5.0.18, does not appear to) If it doesn't then presumably you can so that you end up with: /docs/my/path/to/doc/document1%2F/param1/param2 I might have misunderstood what you are trying to do though. -Original Message- From: Alfie Kirkpatrick alfie.kirkpatr...@ioko.com Reply-To: Tapestry users users@tapestry.apache.org To: Tapestry users users@tapestry.apache.org Subject: RE: T5: Passing named/structured-type params in URLs? Date: Wed, 13 May 2009 12:53:31 +0100 I've been following this thread with interest and have a somewhat different requirement. I have a desire to use a context where the delimeter for one of the values is itself a '/'. For example: /docs/my/path/to/doc/document1/param1/param2 I can do this by hand in a page by having onActivate(EventContext ctx) and iterating the elements of the path. However, what if param2 is optional? Also, it means I have to do this work manually on every page. I realise that to make this work more generally I'd need to have another kind of separator in there, eg: /docs/my/path/to/doc/document1/-/param1/param2 I'd might then have a signature like: void onActivate(DocPath path, Object param1, Object param2) and have the T5 machinery encode/decode urls accordingly. Is this possible or am I asking too much? This is all in a drive to having nice looking URLs... A simpler alternative might be to simply use a different context value separater, eg. '-' for apps where the context values are themselves meaningful paths. Is this possible? This would lead to a url like: /docs/my/path/to/doc/document1-param1-param2 Which kind of works for me. Thanks! Alfie. -Original Message- From: Joel Halbert [mailto:j...@su3analytics.com] Sent: 12 May 2009 17:51 To: Tapestry users Subject: Re: T5: Passing named/structured-type params in URLs? Hi Andy, The same Encoder could indeed be used across multiple pages. Some pointers: You need to create one of these: http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/ValueEncoder.html Look at the source for one of the existing implementation for ideas, e.g. StringEncoder [snip] - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wanted something like this maybe nine months ago and ended up creating my own @RequestParameter annotation, overriding Form, ActionLink, EventLink, and PageLink, and modifying the way Tapestry generates URLs. It works, but it ain't pretty. Anyway, back then, it looked like something like this would be easy enough to implement using a persistence strategy, it would just require some changes to many aspects of URL handling in Tapestry - for one, I remember needing access to the name of the page a Link was for. I think that it would be worthwhile, though - the activation context is great for a lot of things, but as you can tell from this thread, you sometimes need the flexibility offered by request parameters - and that is currently way too hard (compared to how easy most things are) in Tapestry. /Filip On 2009-05-09 00:29, Robert Zeigler wrote: That should work. I think it could be interesting, though, if tapestry provided an additional persistence mechanism, ala: @Persist(PersistenceConstants.QUERY_PARAMETER) private String p; @Persist(PersistenceConstants.QUERY_PARAMETR) private Integer irn; which would then take the values in p and irn and stash them in the url, like: p=valueEncodedValueirn=valueEncodedValue Obviously this wouldn't be appropriate to use everywhere; if you're concerned about users tampering with URLs, you'd want to avoid it. But in cases like that presented below, where you expressly want users to be able to muck about with parameters, it would be useful. Note that this is similar to the current client-side persistence mechanism, except that mechanism a) rolls all persisted values into a single parameter and b) base64 encodes the parameter. As long as you've got the basic mechanism for doing the above, you could translate it into a pretty url via url rewriting without too much trouble. Thoughts? Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKCsjVAAoJEEfiH7PpjaMnWbIIAJdAPuQo5jngCCZt2DSXV5e3 dGG+0wOOnxrmC2jFTDrxVRvWx7dfA4hGuAFPQgz/USP+NviNkEvFz2iGfZTAgmzA 19BFLfx1AdWYu2ft1tPULkBGmxaLa/Rjt0qosHn3+kKo+Kgl0yhDjcZSbx29+Ic6 8eBRn0krOha5o6GU6OU/iIqMEjRvErAOutB63nlRr7oIfuttffucPXDGE0UutQ9v llwzlQoGfk5ywHr0AqJlclA0AH44ePOtxiP4xg3OwgVh9Wge/vHMVGxYURzbp/lf wvqTP3iASZHOYEYpji6/J31awC/3T8gcP+Rm/53VLrDtsU2dHnfzJ+B7hJpjYAk= =SYe3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Sorry one typo: eventContext.get(Integer.class, i) needs to be a String in this
example.
- Original Message -
From: Peter Stavrinides p.stavrini...@albourne.com
To: Tapestry users users@tapestry.apache.org
Sent: Wednesday, 13 May, 2009 17:22:59 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5: Passing named/structured-type params in URLs?
This is an interesting thread, and a way overdue discussion... it has given me
some nice ideas, so let me also share one of mine.
you sometimes need the flexibility offered by request parameters - and that
is currently way too hard (compared to how easy most things are) in
Tapestry.
Yes, I drew the same conclusion after experiencing similar problems... At first
I thought of messing with the URL, but opted out of that because and I like the
clean URL's Tapestry produces and didn't want to mess them up. Since 'request
parameters' are simply stored as a key value pair, i.e.: a map, I figured you
could use reflection and reconstruct them as named parameters with the help of
an Annotation. So I implemented a BasePage with the EventContext interface and
then populated a LinkedHashMap, something like this:
In any given page class:
@ContextVariables(variables = { ContextVariables.DOCUMENT ,
ContextVariables.COMPANY, ...})
...
The base page:
protected Object onActivate(EventContext eventContext) {
String[] context = null;
//Extract annotated variables from the class
if (getClass().isAnnotationPresent(ContextVariables.class)) {
ContextVariables annotation = getClass().getAnnotation(
ContextVariables.class);
context = annotation.variables();
_namedContext = new LinkedHashMapString, String();
// iterate over context variables
for (int i = 0; i eventContext.getCount(); i++) {
// a type check and add
if
(context[i].equals(ContextVariables.DOCUMENT)) {
_namedContext.put(ContextVariables.DOCUMENT, eventContext.get(Integer.class,
i));
}
//more names params etc...
}
}
return null;
}
So I think its fairly clean and flexible solution.
Kind regards,
Peter
- Original Message -
From: Filip S. Adamsen f...@fsadev.com
To: Tapestry users users@tapestry.apache.org
Sent: Wednesday, 13 May, 2009 16:19:17 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: T5: Passing named/structured-type params in URLs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wanted something like this maybe nine months ago and ended up creating
my own @RequestParameter annotation, overriding Form, ActionLink,
EventLink, and PageLink, and modifying the way Tapestry generates URLs.
It works, but it ain't pretty. Anyway, back then, it looked like
something like this would be easy enough to implement using a
persistence strategy, it would just require some changes to many aspects
of URL handling in Tapestry - for one, I remember needing access to the
name of the page a Link was for.
I think that it would be worthwhile, though - the activation context is
great for a lot of things, but as you can tell from this thread, you
sometimes need the flexibility offered by request parameters - and that
is currently way too hard (compared to how easy most things are) in
Tapestry.
/Filip
On 2009-05-09 00:29, Robert Zeigler wrote:
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the url,
like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want users
to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into a
single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you could
translate it into a pretty url via url rewriting without too much
trouble.
Thoughts?
Robert
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBAgAGBQJKCsjVAAoJEEfiH7PpjaMnWbIIAJdAPuQo5jngCCZt2DSXV5e3
dGG
Re: T5: Passing named/structured-type params in URLs?
Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
So, is there a Tapestry meachnism for doing something like this? I can
do it right now, but I'd rather not have to fight the system. I would
expect Tapestry to do it a bit prettier than what I've shown, maybe
*something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's a
value... I just mean this schematically) But right now I don't even
know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a List
populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and reconstruct
the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
Thanks: I've opted to use something similar to this, but with regex
matching instead of twice as many directory levels as expected, e.g.
decoding URLs like
.../view/irn1245569/d1,2,4/x1
in the obvious way. Seems to work fairly well so far, so thanks for the
pointer.
This has sparked an extra question, though: I also want to be able to
render my data records in several different ways, i.e. nice HTML tables
by default, but also structured plain text, XML, plotting code and other
formats on demand. Like the main page, these should be accessible via
the URL. So far, I've been using event handlers, e.g.
.../view:xml?irn=1245569d=1
to call a View.onXML() method. In moving to this new regexy context
encoding, I tried using ActionLinks to make these alternative-format
links, but it doesn't pass the parameters as expected: I have to add an
@OnEvent(component=xml) annotation to the onXML() method for it to
work at all, and when I do that the ActionLink uses a dot in the URL
rather than a colon, and ignores the context. I assume there's some
session magic going on to make it work at all, but it means that the
alternative formats can't be accessed via URLs. If I explicitly build
the URL with the context used before, e.g.
.../view.xml/irn1245569/d1
then I get an exception. Is there a way that I can keep using event
handlers for alternative formats and still pass the context params in
the URL? I'd rather not have to split all these formats off into
separate pages, since each contains relatively little logic and the
context decoding seems best defined in the page class (not least for
class reloading convenience.) Looking forward to more useful answers ;)
By the way, T5 developers, it would be nice if the EventContext was
IterableString, so the old-style for-loop can be replaced with
something more Java 5+ish like for (String s : context) { ... for
those who just want strings back from the URL context. But that's a
minor, minor point! ;)
Thanks again,
Andy
--
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Robert Zeigler wrote: That should work. I think it could be interesting, though, if tapestry provided an additional persistence mechanism, ala: @Persist(PersistenceConstants.QUERY_PARAMETER) private String p; @Persist(PersistenceConstants.QUERY_PARAMETR) private Integer irn; which would then take the values in p and irn and stash them in the url, like: p=valueEncodedValueirn=valueEncodedValue That sounds nice. I've managed to use a variant of the other suggestion with reasonable results, though, so it now works for me. Thanks. I do have another question about ActionLinks and URL params/context being passed to event handlers, so if you're still feeling helpful then feel free to chip in elsewhere on the thread ;) Cheers, Andy -- Dr Andy Buckley Institute for Particle Physics Phenomenology Durham University 0191 3343798 | 0191 3732613 | www.insectnation.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Hi Andy,
The same Encoder could indeed be used across multiple pages.
Some pointers:
You need to create one of these:
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/ValueEncoder.html
Look at the source for one of the existing implementation for ideas,
e.g. StringEncoder
I've attached an example implementation of a MapValueEncoder.java
You will then need to configure your Tap App to use your encoder e.g.
public static void
contributeValueEncoderSource(MappedConfigurationClass,
ValueEncoderFactory configuration) {
configuration.add(Map.class, new
GenericValueEncoderFactoryMap(new
MapValueEncoder()));
}
You can then have activation context's that take a Map e.g.
protected boolean onActivate(Map params) {
id = params.get(id);
}
I'm sure there is a doc page for encoders, although I cann't seem to dig
it out.
-Original Message-
From: Andy Buckley andy.buck...@durham.ac.uk
Reply-To: Tapestry users users@tapestry.apache.org
To: Tapestry users users@tapestry.apache.org
Subject: Re: T5: Passing named/structured-type params in URLs?
Date: Tue, 12 May 2009 16:07:06 +0100
Joel Halbert wrote:
There was a jira feature request raised for named params some time ago:
https://issues.apache.org/jira/browse/TAP5-264
Andy - in the meantime, another alternative is to create a custom
ValueEncoder for activation contexts which can encode and decode a map.
You could then encode the map context using a scheme which uses, for
example, underscores as delimiters, such as:
/mypage/name1_value1_name2_value2
(i.e. /mypage/context)
This would allow you to access params by name from an activation
context.
This works well enough so long as you do not care about using the
correct http request syntax for query strings
(?name1=value1name2=value2).
I've ended up essentially doing this, but more manually via the
onActivate() method of the page. Can you point me at any documentation
on how to do this with a custom ValueEncoder as you've suggested, and
what the benefits would be of doing it that way? (e.g. would this make
it easy to use the same param value encoding scheme on multiple pages?)
Cheers,
Andy
import java.io.UnsupportedEncodingException;
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.util.Iterator;
import java.util.Map;
import org.apache.commons.collections.map.ListOrderedMap;
import org.apache.log4j.Logger;
import org.apache.tapestry5.ValueEncoder;
public class MapValueEncoder implements ValueEncoder {
static final Logger log = Logger.getLogger(MapValueEncoder.class);
private static final String DELIM = _;
@Override
public String toClient(Object value) {
String res = ;
IteratorString it = null;
MapString,Object map = (MapString, Object) value;
if (value instanceof ListOrderedMap) {
ListOrderedMap lomap = (ListOrderedMap) value;
it = lomap.keyList().iterator();
} else {
it = map.keySet().iterator();
}
while(it.hasNext()) {
String key = it.next();
Object val = map.get(key);
if (val != null) {
if (res.length() 0) {
res += DELIM;
}
res += key + DELIM + escapeString(val.toString());
}
}
return res;
}
@Override
public Object toValue(String clientValue) {
String[] tokens = clientValue.split(DELIM);
ListOrderedMap res = new ListOrderedMap();
boolean tokIsKey = true;
String currKey = null;
for (int i = 0; i tokens.length; i++) {
String tok = tokens[i];
if (tokIsKey) {
currKey = tok;
} else {
res.put(currKey, descapeString(tok));
}
tokIsKey = !tokIsKey;
}
return res;
}
public static String escapeString(String string) {
try {
return URLEncoder.encode(string, UTF-8);
} catch (UnsupportedEncodingException e) {
log.error(unable to encode : + string, e);
return ;
}
}
public static String descapeString(String string) {
try {
return URLDecoder.decode(string, UTF-8);
} catch (UnsupportedEncodingException e) {
log.error(unable to descape : + string, e);
return ;
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
There was a jira feature request raised for named params some time ago:
https://issues.apache.org/jira/browse/TAP5-264
Andy - in the meantime, another alternative is to create a custom
ValueEncoder for activation contexts which can encode and decode a map.
You could then encode the map context using a scheme which uses, for
example, underscores as delimiters, such as:
/mypage/name1_value1_name2_value2
(i.e. /mypage/context)
This would allow you to access params by name from an activation
context.
This works well enough so long as you do not care about using the
correct http request syntax for query strings
(?name1=value1name2=value2).
-Original Message-
From: Carl Crowder carl.crow...@taptu.com
Reply-To: Tapestry users users@tapestry.apache.org
To: Tapestry users users@tapestry.apache.org
Subject: Re: T5: Passing named/structured-type params in URLs?
Date: Sat, 09 May 2009 12:05:28 +0100
I did actually try writing something like this a while ago. The problem
is that you need to specify more than just the name of the parameter,
you need to know which component it's part of.
I ended up with urls like:
/page?component1.component2.param=somevaluecomponent1.component3.param2=somevalue
So as you can see, they quickly become very large.
You could mandate that only top-level components (ie, pages) can use
that persistence strategy, but that seems to be counter-intuitive.
I toyed with the idea of mapping those names to some smaller IDs - a
service which simply converts p1 to component1.component2.param so
you could have urls looking like:
/page?p1=somevaluep2=somevalue
The problem then is it's hard to work out what the params actually are
for the user/developer. Also, how do you populate that map to start
with? You'd have to load each page and component class at startup.
I didn't ever finish this code as I worked out how to do what I wanted
with vanilla PageActicationContext in the end.
Robert Zeigler wrote:
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the url,
like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want users
to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into a
single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you could
translate it into a pretty url via url rewriting without too much
trouble.
Thoughts?
Robert
On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
So, is there a Tapestry meachnism for doing something like this? I
can do it right now, but I'd rather not have to fight the system. I
would expect Tapestry to do it a bit prettier than what I've shown,
maybe *something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's a
value... I just mean this schematically) But right now I don't even
know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a List
populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and
reconstruct the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional
Re: T5: Passing named/structured-type params in URLs?
I did actually try writing something like this a while ago. The problem
is that you need to specify more than just the name of the parameter,
you need to know which component it's part of.
I ended up with urls like:
/page?component1.component2.param=somevaluecomponent1.component3.param2=somevalue
So as you can see, they quickly become very large.
You could mandate that only top-level components (ie, pages) can use
that persistence strategy, but that seems to be counter-intuitive.
I toyed with the idea of mapping those names to some smaller IDs - a
service which simply converts p1 to component1.component2.param so
you could have urls looking like:
/page?p1=somevaluep2=somevalue
The problem then is it's hard to work out what the params actually are
for the user/developer. Also, how do you populate that map to start
with? You'd have to load each page and component class at startup.
I didn't ever finish this code as I worked out how to do what I wanted
with vanilla PageActicationContext in the end.
Robert Zeigler wrote:
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the url,
like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want users
to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into a
single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you could
translate it into a pretty url via url rewriting without too much
trouble.
Thoughts?
Robert
On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
So, is there a Tapestry meachnism for doing something like this? I
can do it right now, but I'd rather not have to fight the system. I
would expect Tapestry to do it a bit prettier than what I've shown,
maybe *something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's a
value... I just mean this schematically) But right now I don't even
know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a List
populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and
reconstruct the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
T5: Passing named/structured-type params in URLs?
Hi, I've been using T5 to develop a scientific database Web frontend, and a requirement is that Web visitors need to be able to bookmark pages, i.e. the parameters of what paper, dataset, etc. have to be in the URL. Having looked at the Web documentation and the Packt book, it seemed that PageLinks are the way to do this... and that works very well for passing a single parameter of simple type (I tried Integer and String) via the URL. But it's passed in an unnamed way, i.e. PageLink'ing a parameter of value 1234 makes a URL like .../linkedpage/1234. I need to be able to pass a) one of several roughly equivalent single parameters (because the name of the parameter determines which of the bibliographic key schemes to use when looking up the paper in the database) b) optional extra parameters, to allow specifying only one particular dataset or even data axis in the paper to be viewed c) it would be good to be able to specify multiple datasets, e.g. to construct a bookmarkable URL which displays datasets 1, 2 and 4 of a given paper. I'd naively expect to be able to do this by passing a Collection of the values to PageLink, but haven't even tested if this works as I wanted to get your collective advice first! I can do these things by hand, and in fact am doing so at the moment, but it's by using normal URL query strings which is not really the Tapestry way. It also means that life is rather awkward as I have to manually do the URL encoding and getting the query params and context path by accessing the Request. Yuck. In short, I'd like to employ the Tapestry way of having a single page where various ways of slicing the data are accessed via a sort of URL API scheme semantically similar to this: .../view?p=1234 .../view?irn=12349876 (these first two are two ways to access all the data in the same paper) .../view?p=1234d=1 (view one dataset only) .../view?p=1234d=1y=2 (view one axis of one axis of one dataset only) .../view?p=1234d=1,2,4y=1,3 (view specific axes of specific datasets only... I wouldn't provide links like this, but users who want specific data might construct them themselves --- hence why I called the URL scheme an API) So, is there a Tapestry meachnism for doing something like this? I can do it right now, but I'd rather not have to fight the system. I would expect Tapestry to do it a bit prettier than what I've shown, maybe *something* like .../view/irn/12349876/d/1,2,4 (yes, there are issues with telling what's a param name and what's a value... I just mean this schematically) But right now I don't even know where to start looking! Help, please!? ;) Thanks in advance... Andy - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley
andy.buck...@durham.ac.uk escreveu:
So, is there a Tapestry meachnism for doing something like this? I can
do it right now, but I'd rather not have to fight the system. I would
expect Tapestry to do it a bit prettier than what I've shown, maybe
*something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's a
value... I just mean this schematically) But right now I don't even know
where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named parameter
one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a List
populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and reconstruct
the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of String,
you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the
url, like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want users
to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into a
single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you
could translate it into a pretty url via url rewriting without too
much trouble.
Thoughts?
Robert
On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley andy.buck...@durham.ac.uk
escreveu:
So, is there a Tapestry meachnism for doing something like this? I
can do it right now, but I'd rather not have to fight the system. I
would expect Tapestry to do it a bit prettier than what I've shown,
maybe *something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's
a value... I just mean this schematically) But right now I don't
even know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a
List populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and
reconstruct the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Have you tried Request Parameters. They do the job well. See:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/state/passingdatabetweenpages1
Geoff
http://jumpstart.doublenegative.com.au
On 09/05/2009, at 8:29 AM, Robert Zeigler wrote:
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the
url, like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want
users to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into
a single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you
could translate it into a pretty url via url rewriting without too
much trouble.
Thoughts?
Robert
On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley andy.buck...@durham.ac.uk
escreveu:
So, is there a Tapestry meachnism for doing something like this? I
can do it right now, but I'd rather not have to fight the system.
I would expect Tapestry to do it a bit prettier than what I've
shown, maybe *something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and what's
a value... I just mean this schematically) But right now I don't
even know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a
List populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and
reconstruct the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Passing named/structured-type params in URLs?
Right.
You can certainly use request parameters, and the poster, in fact, /
is/ using request parameters currently.
But that's painful. You have to manage the parameters and wrangle
type coercion manually. If you're doing this a lot, that's a lot of
repetitive boiler-plate code.
Which sounds exactly like something tapestry should be able to take
care of for you. Sort of like how the @PageActivationContext makes
life a lot easier for the pages out there with a single activation
context.
Robert
On May 9, 2009, at 5/912:06 AM , Geoff Callender wrote:
Have you tried Request Parameters. They do the job well. See:
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/state/passingdatabetweenpages1
Geoff
http://jumpstart.doublenegative.com.au
On 09/05/2009, at 8:29 AM, Robert Zeigler wrote:
That should work.
I think it could be interesting, though, if tapestry provided an
additional persistence mechanism, ala:
@Persist(PersistenceConstants.QUERY_PARAMETER)
private String p;
@Persist(PersistenceConstants.QUERY_PARAMETR)
private Integer irn;
which would then take the values in p and irn and stash them in the
url, like:
p=valueEncodedValueirn=valueEncodedValue
Obviously this wouldn't be appropriate to use everywhere; if you're
concerned about users tampering with URLs, you'd want to avoid it.
But in cases like that presented below, where you expressly want
users to be able to muck about with parameters, it would be useful.
Note that this is similar to the current client-side persistence
mechanism, except that mechanism a) rolls all persisted values into
a single parameter and b) base64 encodes the parameter.
As long as you've got the basic mechanism for doing the above, you
could translate it into a pretty url via url rewriting without
too much trouble.
Thoughts?
Robert
On May 8, 2009, at 5/83:59 PM , Thiago H. de Paula Figueiredo wrote:
Em Fri, 08 May 2009 17:39:07 -0300, Andy Buckley andy.buck...@durham.ac.uk
escreveu:
So, is there a Tapestry meachnism for doing something like this?
I can do it right now, but I'd rather not have to fight the
system. I would expect Tapestry to do it a bit prettier than what
I've shown, maybe *something* like
.../view/irn/12349876/d/1,2,4
(yes, there are issues with telling what's a param name and
what's a value... I just mean this schematically) But right now I
don't even know where to start looking! Help, please!? ;)
Just use a List as the activation context value. For each named
parameter one want, add the name first, the value second.
The above URL would be constructed by Tapestry if you returned a
List populated like this:
List list = new ArrayList();
list.add(irn);
list.add(1245569);
list.add(d);
list.add(1,2,4);
Then, declare a onActivate(EventContext context) method and
reconstruct the pairs:
for (int i = 0; i context.getCount() / 2; i++) {
String name = context.get(String.class, i * 2);
String value = context.get(String.class, i * 2 + 1) // instead of
String, you could use any type here
}
I have not tested this code, but I guess you get the idea. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
