Exactly, and the actually implementation (already checked in)
documents this distinction.
On Tue, Mar 24, 2009 at 10:18 AM, Robert Zeigler <robe...@scazdl.org> wrote:
> +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
>
>
--
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
