You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Erik Hatcher <er...@ehatchersolutions.com> on 2005/03/23 10:42:42 UTC
DirectLink followed by redirect
A common pattern I've been implementing is to throw a RedirectException
in my listener methods from form submits or DirectLink's. I want to
ensure the browser's URL is always bookmarkable and refreshable. A
DirectLink to add an item to a shopping cart would add the item again
when refreshed.
Are others doing this? Has anyone come up with clever and clean ways
to generalize this?
I'm considering implementing my own link service and component that
would redirect after the trigger, parameterizable on the link component
somehow. The defaults of redirecting to the current page as if it was
a PageLink would be ok, and if parameters are specified then redirect
like its an ExternalLink. Reasonable? What am I missing?
On a related note ExternalLink is beginning to frustrate me. I'd like
to be able to link to a page, pass it _named_ parameters and have the
page just get them automatically. Having to implement another
interface and ensure parameters are ordered is too brittle. I'd like a
link component/service that links to a page optionally with informal
named parameters, and sets the property for those names before
activating the page. That seems like it'd simplify a lot of what I do.
What else would something like this need to be robust and
generalizable?
Maybe there could be one link component to rule them all? :) Maybe
this isn't so far fetched, if a listener is not specified then it acts
as the named parameter link to just activate the page, but if a
listener is specified it still sets the parameters and then calls the
listener. Drawbacks?
Thanks,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: DirectLink followed by redirect
Posted by Stephen Yau <st...@ocean.hk>.
I have implemented similar solution on my side. It is base on what
Konstantin suggested long time ago:
http://article.gmane.org/gmane.comp.java.tapestry.user/3580
Basically, I have my own RequestCycle with a Boolean call
"redirectAsRedirect", but unlike Konstantin implementation, I have override
renderResponse method in the BaseEngine to detect whether the current cycle
should be render as redirect. If it should, then the following method will
be invoked:
protected void renderRedirect(IRequestCycle pCycle,
ResponseOutputStream pResponseOutputStream) {
HttpServletResponse response =
pCycle.getRequestContext().getResponse();
IEngineService service = getService(Tapestry.PAGE_SERVICE);
String pageName = pCycle.getPage().getPageName();
ILink link = service.getLink(pCycle, null, new String[] { pageName
});
try {
response.sendRedirect(link.getURL());
} catch (IOException e) {
throw new ApplicationRuntimeException(e.getMessage(), pCycle
.getPage(), null, e);
}
}
So far so good on my side, and it seem much more clear to me than throwing a
RedirectException.
-----Original Message-----
From: Jamie Orchard-Hays [mailto:jamie@dang.com]
Sent: Wednesday, March 23, 2005 11:11 PM
To: Tapestry users
Subject: Re: DirectLink followed by redirect
I'm with you on the RedirectException. This is something that really
Tapestry should take care of. It's a common pattern in any Web
development to prevent refreshing of form submissions.
Jamie
On Mar 23, 2005, at 4:42 AM, Erik Hatcher wrote:
> A common pattern I've been implementing is to throw a
> RedirectException in my listener methods from form submits or
> DirectLink's. I want to ensure the browser's URL is always
> bookmarkable and refreshable. A DirectLink to add an item to a
> shopping cart would add the item again when refreshed.
>
> Are others doing this? Has anyone come up with clever and clean ways
> to generalize this?
>
> I'm considering implementing my own link service and component that
> would redirect after the trigger, parameterizable on the link
> component somehow. The defaults of redirecting to the current page as
> if it was a PageLink would be ok, and if parameters are specified then
> redirect like its an ExternalLink. Reasonable? What am I missing?
>
> On a related note ExternalLink is beginning to frustrate me. I'd like
> to be able to link to a page, pass it _named_ parameters and have the
> page just get them automatically. Having to implement another
> interface and ensure parameters are ordered is too brittle. I'd like
> a link component/service that links to a page optionally with informal
> named parameters, and sets the property for those names before
> activating the page. That seems like it'd simplify a lot of what I
> do. What else would something like this need to be robust and
> generalizable?
>
> Maybe there could be one link component to rule them all? :) Maybe
> this isn't so far fetched, if a listener is not specified then it acts
> as the named parameter link to just activate the page, but if a
> listener is specified it still sets the parameters and then calls the
> listener. Drawbacks?
>
> Thanks,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Jamie Orchard-Hays <ja...@dang.com>.
I'm with you on the RedirectException. This is something that really
Tapestry should take care of. It's a common pattern in any Web
development to prevent refreshing of form submissions.
Jamie
On Mar 23, 2005, at 4:42 AM, Erik Hatcher wrote:
> A common pattern I've been implementing is to throw a
> RedirectException in my listener methods from form submits or
> DirectLink's. I want to ensure the browser's URL is always
> bookmarkable and refreshable. A DirectLink to add an item to a
> shopping cart would add the item again when refreshed.
>
> Are others doing this? Has anyone come up with clever and clean ways
> to generalize this?
>
> I'm considering implementing my own link service and component that
> would redirect after the trigger, parameterizable on the link
> component somehow. The defaults of redirecting to the current page as
> if it was a PageLink would be ok, and if parameters are specified then
> redirect like its an ExternalLink. Reasonable? What am I missing?
>
> On a related note ExternalLink is beginning to frustrate me. I'd like
> to be able to link to a page, pass it _named_ parameters and have the
> page just get them automatically. Having to implement another
> interface and ensure parameters are ordered is too brittle. I'd like
> a link component/service that links to a page optionally with informal
> named parameters, and sets the property for those names before
> activating the page. That seems like it'd simplify a lot of what I
> do. What else would something like this need to be robust and
> generalizable?
>
> Maybe there could be one link component to rule them all? :) Maybe
> this isn't so far fetched, if a listener is not specified then it acts
> as the named parameter link to just activate the page, but if a
> listener is specified it still sets the parameters and then calls the
> listener. Drawbacks?
>
> Thanks,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Documentation on adding component libraries to Tapestry Palette
Posted by Michael Henderson <mh...@mac.com>.
Hi,
I have put a document describing the method for publishing component
libraries via the Tapestry Palette:
http://tapestrypalette.sourceforge.net/docs/integrating-component-
libraries.shtml
Once you have the supplier descriptor file available for the palette,
users can view your library, or libraries, and download the library
from within the palette and start using it immediately.
The article describes the minimum requirement for integrating a library
with the palette. I'm working on a second section describing how to
incorporate structure information into the library itself so that the
palette can display a folder structure for the library, and you can
declare the format strings used for editing templates when the
component is dragged and dropped.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Kent Tong <ke...@cpttm.org.mo>.
Erik Hatcher <erik <at> ehatchersolutions.com> writes:
> A PageLink is already "external" and redirecting seems silly to me.
> Can you provide an example of when you'd want to redirect after a
> PageLink is activated?
You're right. It's a poor example. Handling form submission
would have been much better.
> I don't have any thoughts on what you've proposed. I think you're on
> to an abstraction that seems needed - separating the response out a
> bit. However, I don't see a pragmatic need to introduce this to
> accomplish what I need.
I agree that if it's not what you need, then don't bother.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 24, 2005, at 10:32 PM, Kent Tong wrote:
> Erik Hatcher <erik <at> ehatchersolutions.com> writes:
>
>> Is this something desirable to have built into Tapestry? If so, is my
>> approach on track to mesh with the framework appropriately?
>
> As I am not closedly following this thread, my suggestion
> may not make sense. Anyway, I think there are two issues
> are being addressed:
> (1) support named parameters.
> (2) show the response using a client redirect.
>
> I think these two issues should be handled separately.
> For example, your ParamService and ParamLink are handling
> issue (1) fine. However, it is unnecessary to couple
> the redirect behavior to your ParamService.
I agree that I'm mixing these two concerns that really are separate.
But, DirectLink's (and soon Form submits) are the only links I'm
concerned with at the moment.
> For example,
> a page activated by the page service may want to use
> this redirect behavior to show the response too
A PageLink is already "external" and redirecting seems silly to me.
Can you provide an example of when you'd want to redirect after a
PageLink is activated? Another issue is that of being able to merge
PageLink and ExternalLink (at least within my application) and being
able to provide parameters optionally to such links, in a named way.
The main point of my effort is to allow the browser's URL to
consistently be in a state of being reloadable and even bookmarkable.
PageLink's to me are already that.
> . Therefore,
> I think the request cycle should support a concept of
> an abstract "Response". At the moment this Response has
> to be a page. You'd like to it to be for a redirect to a
> page. Some use cases (eg, file download) would like it to
> be nothing. So, the "Response" hierarchy may be like:
I don't have any thoughts on what you've proposed. I think you're on
to an abstraction that seems needed - separating the response out a
bit. However, I don't see a pragmatic need to introduce this to
accomplish what I need.
Erik
>
> interface Response { ... }
>
> //existing support for bucket brigate
> class PageResponse implements Response { ... }
>
> class ClientRedirectResponse implements Response { ... }
>
> //what Erik needs for now
> class PageClientRedirectResponse extends ClientRedirectResponse { ... }
>
> //redirect to a page using named params
> class ParamPageClientRedirectResponse extends ClientRedirectResponse {
> ... }
>
> //for file downloads
> class NullResponse implements Response { ... }
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Kent Tong <ke...@cpttm.org.mo>.
Erik Hatcher <erik <at> ehatchersolutions.com> writes:
> Is this something desirable to have built into Tapestry? If so, is my
> approach on track to mesh with the framework appropriately?
As I am not closedly following this thread, my suggestion
may not make sense. Anyway, I think there are two issues
are being addressed:
(1) support named parameters.
(2) show the response using a client redirect.
I think these two issues should be handled separately.
For example, your ParamService and ParamLink are handling
issue (1) fine. However, it is unnecessary to couple
the redirect behavior to your ParamService. For example,
a page activated by the page service may want to use
this redirect behavior to show the response too. Therefore,
I think the request cycle should support a concept of
an abstract "Response". At the moment this Response has
to be a page. You'd like to it to be for a redirect to a
page. Some use cases (eg, file download) would like it to
be nothing. So, the "Response" hierarchy may be like:
interface Response { ... }
//existing support for bucket brigate
class PageResponse implements Response { ... }
class ClientRedirectResponse implements Response { ... }
//what Erik needs for now
class PageClientRedirectResponse extends ClientRedirectResponse { ... }
//redirect to a page using named params
class ParamPageClientRedirectResponse extends ClientRedirectResponse { ... }
//for file downloads
class NullResponse implements Response { ... }
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 24, 2005, at 6:43 PM, Steven Porter wrote:
> So, presumably ParamLink takes all the informal parameters that it
> doesn't
> recognise or are not reserved parameter names and assumes that they
> are put
> into the Map for the trigger?
That is exactly what it does. I borrowed that bit of logic from
AbstractComponent's renderInformalParameters.
> Presumably you can indicate the page name using
>
> <a jwcid="@ParamLink" listener="ognl:listeners.remove"
> index="ognl:index"
> page="mypage">Delete</a>
>
> But how will you use arbitrary named parameters for the external link?
> How
> will ParamLink or the ParamService know which informal params are for
> the
> external link only?
Great questions, and ones I haven't fleshed out. The map idea you show
below is reasonable:
> The only way I can think of is
>
> <a jwcid="@ParamLink" listener="ognl:listeners.remove"
> index="ognl:index"
> page="mypage"
>
> externalParams='ognl:{"foo":"foovalue","bar":"barvalue"}'>Delete</a
>
> Which is not as nice as it was when it was just a simple page and not
> an
> external page...
>
> Any better ideas?
I actually don't even mind something like this:
<a jwcid="@ParamLink" listener="ognl:listeners.remove"
listenerParams="ognl:#{'index':index}"
redirectPage="AnotherPage"
redirectParams="ognl:#{'foo': fooValue, 'bar':
barValue}">Delete</a>
Two main things I want to achieve are named parameters and redirecting
after a listener is called. Named parameters are much less brittle and
easier to visually recognize.
Potentially related, I'm still after getting rid of my use of
IExternalPage by having a link/service that set page properties
automatically. Ideally I'd like something that is simple to use that
generates bookmarkable and clean URL's, and this overlaps with the
DirectLink-like tweaks I've just made. I'll build these things as I
need them in my current project.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: DirectLink followed by redirect
Posted by Steven Porter <sp...@yahoo.co.uk>.
So, presumably ParamLink takes all the informal parameters that it doesn't
recognise or are not reserved parameter names and assumes that they are put
into the Map for the trigger?
Presumably you can indicate the page name using
<a jwcid="@ParamLink" listener="ognl:listeners.remove"
index="ognl:index"
page="mypage">Delete</a>
But how will you use arbitrary named parameters for the external link? How
will ParamLink or the ParamService know which informal params are for the
external link only?
The only way I can think of is
<a jwcid="@ParamLink" listener="ognl:listeners.remove"
index="ognl:index"
page="mypage"
externalParams='ognl:{"foo":"foovalue","bar":"barvalue"}'>Delete</a
>
Which is not as nice as it was when it was just a simple page and not an
external page...
Any better ideas?
sp
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 23, 2005, at 8:22 PM, Erik Hatcher wrote:
>> The only niggle I see is that the URL needs to be generatable via the
>>
>> "IEngineService.getLink(IRequestCycle cycle, IComponent component,
>> Object[]
>> parameters)"
>
> No problem there. I'd pass in a Map of name/value pairs as one of the
> parameters.
Status report.... I've gotten a basic ParamService and ParamLink combo
working well enough for my needs right now. Links look like this:
<a jwcid="@ParamLink" listener="ognl:listeners.remove"
index="ognl:index">Delete</a>
And my listener method looks like this:
public void remove(IRequestCycle cycle) {
Map map = (Map) cycle.getServiceParameters()[0];
Integer position = (Integer) map.get("index");
Page page = getExhibitPage();
page.remove(position.intValue());
}
The URL looks like this:
/app?
component=%24ParamLink%242&index=1&page=Page&service=param&session=T
My service currently only redirects to the page as a PageLink, though
I'll have to enhance that I'm sure.
Is this something desirable to have built into Tapestry? If so, is my
approach on track to mesh with the framework appropriately?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: DirectLink followed by redirect
Posted by Steven Porter <st...@site-intelligence.co.uk>.
> No need to use reflection directly.... I'll simply call
> IPage.setProperty(name, value).
Ah, much nicer.
> I've successfully gotten a service working on its own, but then decided
> that overriding DirectService was a better way to hook in a redirect
> transparently. It was trivial to override DirectService with HiveMind
> (thank you Howard!). I've created a custom link component (and called
> it DirectLink also) and it overrode the built-in one pleasantly.
>
> So I've got a start on the redirect side of this. What types of
> parameters would need to be factored into a redirect URL? I intend to
> start quite straightforwardly and have it simply redirect to the active
> page as a PageLink initially. And then tack on some way to add
> parameters for the redirect - perhaps just using the parameters
> attribute of my custom DirectLink in the ways described above if it is
> a Map. Getting warmer? What's desired here?
OK, ignoring the named-parameters here and just sticking to redirection -
The DirectLink needs to encode the usual direct link parameters (component
path and trigger parameters), but then additionally also encode the
redirection (which service to redirect to, and which parameters for that).
In the general case, you want to encode the "redirect-to" service name and
the "redirect-to" service parameters.
You need to think a little about how to separate the "normal direct link"
part of the URL from the "redirect-to" part. This is because the parameters
for the direct link are not a fixed number. Simple solution is just to
encode some sort of delimiter parameter. Or perhaps a better solution is to
wrap up the whole lot such that
param[0] is a list/array of params for the direct service
param[1] is the service name for the redirection (e.g., page or external)
param[2] is the list/array of params for the chosen redirection service
To make things transparent to the trigger, your implementation of
DirectService needs to strip out the "redirect" parameters from the
cycle.getServiceParameters() before calling the trigger (otherwise the
trigger will receive too many parameters, and every trigger would need to
know to ignore these), and ensure that they look just as they would without
the redirection stuff. It would be nice for all "old" trigger code to be
compatible here.
Then once the trigger is processed, in your direct service you throw the
redirect exception, using the original direct service call's "redirect-to"
parameters to generate the url: param[1] above is the service name (ie,
normally page or external), the param[2] array is passed on as params to
service.getLink(...)
Your link component might want to have a few versions to specialize on the
page service for redirection and external service for redirection (or
perhaps combine the two into one link component: 0 params means use page
service, >0 params means use external service). These link components are
kinda equivalent to a combination of DirectLink followed by automatic
PageLink/ExternalLink.
The above service could potentially handle ALL redirections after a direct
trigger since it is not specific to any particular service, because we
encode the "redirect-to" service name and params within the trigger URL.
Cheers
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink followed by redirect
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 23, 2005, at 8:04 AM, Steven Porter wrote:
>> On a related note ExternalLink is beginning to frustrate me. I'd like
>> to be able to link to a page, pass it _named_ parameters and have the
>> page just get them automatically. Having to implement another
>> interface and ensure parameters are ordered is too brittle.
>
> So, first thought would be to write a service that is similar to the
> ExternalService, but which uses JavaBeans-style reflection to set the
> properties on the page rather than make use of the IExternalPage
> interface.
No need to use reflection directly.... I'll simply call
IPage.setProperty(name, value). The risk is that there is a URL
parameter that does not correspond with a property name - so that
exception would need to be caught (unless there is a way to see if a
page has a property before trying to set it that I haven't discovered
yet).
> The only niggle I see is that the URL needs to be generatable via the
>
> "IEngineService.getLink(IRequestCycle cycle, IComponent component,
> Object[]
> parameters)"
No problem there. I'd pass in a Map of name/value pairs as one of the
parameters.
> It's important that IEngineService.getLink(...) and
> IEngineService.service(...) methods produce/consume compatible URLs:
> this is
> one of the key design decisions that makes Tapestry as good as it is.
>
> Once you've got the service written, writing the equivalent link
> component
> is simple enough.
>
> As you suggest, in this way, you could treat any page as if it were an
> "external page", without the need to implement any fancy IExternalPage
> interface.
I've successfully gotten a service working on its own, but then decided
that overriding DirectService was a better way to hook in a redirect
transparently. It was trivial to override DirectService with HiveMind
(thank you Howard!). I've created a custom link component (and called
it DirectLink also) and it overrode the built-in one pleasantly.
So I've got a start on the redirect side of this. What types of
parameters would need to be factored into a redirect URL? I intend to
start quite straightforwardly and have it simply redirect to the active
page as a PageLink initially. And then tack on some way to add
parameters for the redirect - perhaps just using the parameters
attribute of my custom DirectLink in the ways described above if it is
a Map. Getting warmer? What's desired here?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: DirectLink followed by redirect
Posted by Steven Porter <st...@site-intelligence.co.uk>.
> On a related note ExternalLink is beginning to frustrate me. I'd like
> to be able to link to a page, pass it _named_ parameters and have the
> page just get them automatically. Having to implement another
> interface and ensure parameters are ordered is too brittle.
So, first thought would be to write a service that is similar to the
ExternalService, but which uses JavaBeans-style reflection to set the
properties on the page rather than make use of the IExternalPage interface.
The only niggle I see is that the URL needs to be generatable via the
"IEngineService.getLink(IRequestCycle cycle, IComponent component, Object[]
parameters)"
method. So you'd need some special classes that wrapped up the named
properties and values pairs to satisfy the "parameters" object. They are
really just name-value pairs, and a simple Map would suffice. You'd need
some mechanism for turning the "name-value" pairs into a URL: easy enough,
just expand it out into individual parameters in the order
property1,value1,property2,value2,etc.
It's important that IEngineService.getLink(...) and
IEngineService.service(...) methods produce/consume compatible URLs: this is
one of the key design decisions that makes Tapestry as good as it is.
Once you've got the service written, writing the equivalent link component
is simple enough.
As you suggest, in this way, you could treat any page as if it were an
"external page", without the need to implement any fancy IExternalPage
interface.
Cheers
Steve
> I'd like a
> link component/service that links to a page optionally with informal
> named parameters, and sets the property for those names before
> activating the page. That seems like it'd simplify a lot of what I do.
> What else would something like this need to be robust and
> generalizable?
>
> Maybe there could be one link component to rule them all? :) Maybe
> this isn't so far fetched, if a listener is not specified then it acts
> as the named parameter link to just activate the page, but if a
> listener is specified it still sets the parameters and then calls the
> listener. Drawbacks?
>
> Thanks,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org