+1.
I assume the difference between createPageRenderLink and
createPageRenderLinkWithContext is that if the context is empty in
with context, you're going to override the page's passivate context
with an empty context, whereas with createPageRenderLink, you let the
page supply it's own context?
Robert
On Mar 24, 2009, at 3/2411:40 AM , Howard Lewis Ship wrote:
I think there needs to be a facade service to make this easier: a
PageLinkSource.
public interface PageRenderLinkSource
{
Link createPageRenderLink(String pageName);
Link createPageRenderLinkWithContext(String pageName, Object...
context);
Link createPageRenderLink(Class pageClass);
Link createPageRenderLinkWithContet(Class pageClass, Object...
context);
}
On Tue, Mar 24, 2009 at 6:20 AM, Robert Zeigler <robe...@scazdl.org>
wrote:
I think that's ugly. :)
Consider:
componentSource
.getPage
(Index
.class).getComponentResources().createPageLink(Index.class,true);
Personally, I get suspicious of call chains nested more than about
two-deep... smells of tight coupling.
Ultimately, componentResources.createPageLink calls into
LinkSource, which
calls into ComponentEvenLinkEncoder to create the link. *shrug*.
Why not bypass the nastiness and go straight to
ComponentEventLinkEncoder?
It /is/ a public service, after all... Personally, though, I wonder
if it
should be the other way around: ComponentEventLinkEncoder really
exposes too
much of the internal "guts" of how tapestry "thinks" about
requests: page
names, nested component ids, etc. (In the form of the
PageRequestParameters
and ComponentEventRequestParameters objects. In that regard, using
component resources is "correct" because it "hides" all of the gory
details...
Except that it still requires an ugly rats' nest of method calls.
Creating
links to pages from within services seems like such a common paradigm
(redirecting to the login page on authentication failure, for
example);
maybe we ought to have cleaner, public support for it...
Robert
On Mar 23, 2009, at 3/2310:47 AM , Howard Lewis Ship wrote:
The correct approach is to use ComponentSource
(http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentSource.html
)
to acquire a page.
You can then get its ComponentResources and generate a page render
Link from the resources.
On Mon, Mar 23, 2009 at 8:36 AM, Massimo Lusetti
<mluse...@gmail.com>
wrote:
On Mon, Mar 23, 2009 at 4:29 PM, Robert Zeigler
<robe...@scazdl.org>
wrote:
If you want to stick with public services, and you're using 5.1,
you can
use:
http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventLinkEncoder.html
I don't think it's quite as convenient to use as LinkSource, but
at
least
it's public. :)
I think that's the better bet we can have and that has been made
for
similar use cases.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
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
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
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
