You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Massimo Lusetti <ml...@gmail.com> on 2013/02/06 18:17:30 UTC

Re: How to handle 404 nicely (TAP5-879)

I think that we have reached an agreement.

Howard is now busy on his own second most important 'project' but I think
we can go further and implement what we have said, after all we still alpha.

On Mon, Jan 28, 2013 at 10:50 PM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:

> On Mon, Jan 28, 2013 at 11:31 AM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > On Mon, 28 Jan 2013 17:02:48 -0200, Kalle Korhonen <
> > kalle.o.korhonen@gmail.com> wrote:
> >
> >> As evident from responses though, it's not easy to pick a winner from
> the
> >> proposed half solutions. I think it's going to come down to being able
> to
> >> somehow handle 404s with onActivate(EventContext) present.
> >>
> >  From tapestry-core side, I don't think that's possible. It would need
> > psychic powers. Our suggestion is adding automatically the 404 logic for
> > pages without any onActivate() method. Now I think we could exclude
> > parameterless onActivate() from this logic.
> >
>
> I was thinking more along the lines of added annotation or added attributes
> than psychic powers.
>
>
> > I agree with Massimo though, a completely
> >
> >> new annotation just for this doesn't sound very lucrative. Perhaps a new
> >> attribute to @OnEvent - although I don't know if it can be as useful for
> >> other than activate event types.
> >>
> >  Almost all "activate" event handler methods are using the method name
> > convention (aka onActivate(...)), so the attribute in @OnEvent would be
> > almost useless for handling 404 errors, specially in already existing
> code.
> > The Steve's solution already covers most pages without any source code
> > change.
> >
>
> Right, which is exactly what we want. We *don't* suddenly want to start
> handling 404s for existing code.
>
> Kalle
>



-- 
Massimo
http://meridio.blogspot.com

Re: How to handle 404 nicely (TAP5-879)

Posted by Ulrich Stärk <ul...@spielviel.de>.
I'd prefer a vote to document the concensus for future reference.

Uli

On 06.02.2013 18:17, Massimo Lusetti wrote:
> I think that we have reached an agreement.
> 
> Howard is now busy on his own second most important 'project' but I think
> we can go further and implement what we have said, after all we still alpha.
> 
> On Mon, Jan 28, 2013 at 10:50 PM, Kalle Korhonen <kalle.o.korhonen@gmail.com
>> wrote:
> 
>> On Mon, Jan 28, 2013 at 11:31 AM, Thiago H de Paula Figueiredo <
>> thiagohp@gmail.com> wrote:
>>
>>> On Mon, 28 Jan 2013 17:02:48 -0200, Kalle Korhonen <
>>> kalle.o.korhonen@gmail.com> wrote:
>>>
>>>> As evident from responses though, it's not easy to pick a winner from
>> the
>>>> proposed half solutions. I think it's going to come down to being able
>> to
>>>> somehow handle 404s with onActivate(EventContext) present.
>>>>
>>>  From tapestry-core side, I don't think that's possible. It would need
>>> psychic powers. Our suggestion is adding automatically the 404 logic for
>>> pages without any onActivate() method. Now I think we could exclude
>>> parameterless onActivate() from this logic.
>>>
>>
>> I was thinking more along the lines of added annotation or added attributes
>> than psychic powers.
>>
>>
>>> I agree with Massimo though, a completely
>>>
>>>> new annotation just for this doesn't sound very lucrative. Perhaps a new
>>>> attribute to @OnEvent - although I don't know if it can be as useful for
>>>> other than activate event types.
>>>>
>>>  Almost all "activate" event handler methods are using the method name
>>> convention (aka onActivate(...)), so the attribute in @OnEvent would be
>>> almost useless for handling 404 errors, specially in already existing
>> code.
>>> The Steve's solution already covers most pages without any source code
>>> change.
>>>
>>
>> Right, which is exactly what we want. We *don't* suddenly want to start
>> handling 404s for existing code.
>>
>> Kalle
>>
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org