On Tue, Dec 8, 2009 at 10:02 AM, ningdh <ningd...@gmail.com> wrote:
> I can't think of a better way not to involve the field name encoded.
Yes, I understand why you did it.
> And if you don't like the field name exposed, you can also customize the
> param name by setting the annotation value, such as
> @PageActivationUnit("cat")
Oh, that's cool, didn't read your source that carefully... thanks for
that btw. I need to ponder about this a bit - I'd like to find a good,
generic pattern to follow.
Kalle
> ----- Original Message -----
> From: "Kalle Korhonen"
> To: "Tapestry users" <users@tapestry.apache.org>
> Sent: Wednesday, December 09, 2009 1:49 AM
> Subject: Re: Best practice for initializing page to default context
>
>
>> On Tue, Dec 8, 2009 at 3:39 AM, Thiago H. de Paula Figueiredo
>> <thiag...@gmail.com> wrote:
>>> Em Tue, 08 Dec 2009 04:22:58 -0200, Kalle Korhonen
>>> <kalle.o.korho...@gmail.com> escreveu:
>>>> and subsequently, if my page has multiple entry points, I typically
>>>> resort to implementing it in a single onActivate(EventContext
>>>> eventContext) operation containing a big if-else clause.
>>> That's the recommended way when you have a variable number of activation
>>> context parameters.
>>
>> DH's approach looks interesting, but maybe a bit involving with field
>> names encoded to the url. Thiago, I know it's the recommended approach
>> but I'm just saying it doesn't strike me as the ideal approach.
>>
>>>> Since the activation context is anyway sent with an event request (as in
>>>> ?t:ac=mycontext), rather than using the encoded context for rendering,
>>>> wouldn't it be just simpler if that context was used for activating
>>>> the page for the event request and the following redirect for
>>>> rendering would just use whatever context onPassivate() returns?
>>> The activation context is always what onPassivate() returns. I don't
>>> understand what is the problem here.
>>
>> That sounds like "I don't understand and don't want to hear about it"
>> - why bother responding if that's the case? Now I'm not sure if it's
>> worth my time to write more details or sample code to describe what I
>> mean if you are not interested in explaining or exploring how to do it
>> better.
>>
>> Kalle
>>
>> ---------------------------------------------------------------------
>> 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
