I am also of the opinion that all missing links terminating to Index page is not useful. I always end-up with some code trying to prevent it.
On Jan 28, 2013, at 2:57 PM, Ulrich Stärk wrote: > There is no need to fight. Discuss your idea and try to achieve concensus. If > necessary call a vote. > Or else, if you feel the change is small, or concensus is already there, just > do it. > > Uli > > On 28.01.2013 03:15, Kalle Korhonen wrote: >> On Sun, Jan 27, 2013 at 1:49 PM, Massimo Lusetti <mluse...@gmail.com> wrote: >> >>> On Sun, Jan 27, 2013 at 10:25 PM, Kalle Korhonen < >>> kalle.o.korho...@gmail.com >>>> My typical pattern is don't use Index pages, use servlet standard error >>>> code mapping to Tapestry error pages, e.g: >>> >> I want exactly the same, but I want to be able to use Index as I remember, >>> for example, that the Start page is somehow deprecated in flavor of Index >>> ones... Someone correct me if I'm wrong. >>> >> >> Yes, support for Start page was completely removed... perhaps in 5.3. In my >> opinion, Start page had it right functionality wise. >> >>> I use Tynamo's tapestry-routing (http://tynamo.org/tapestry-routing+guide) >>>> for "folder-specific" index pages, e.g: >>>> @At("/") >>>> public class Home {...} >>>> I've always found Tapestry's Index page handing to be too far reaching. >>> I don't want to use something "external" to achieve this. I think it should >>> be part of the standard page handling/processing mechanism. >>> Now I'm thinking about a way to reach the goal without changing the >>> "semantic" of page request handling cause now if you have an index page >>> with: >>> void onActivate(String test) >>> { >>> System.out.println("first context parameter: " + test); >>> } >>> if I call the url: /first/second/third ... My activation context method is >>> called with the first parameter and the other discarded... My vision is >>> that this should result in a 404. >>> >> >> And what about onActivate(EventContext context)? If you could limit the >> number of accepted parameters(an annotation parameter perhaps?), then that >> might work. However, I'm often too much of a pragmatist to try to convince >> Howard of what the framework should or shouldn't do. I'm usually happy with >> the inherent "change it if you don't like it" flexibility of the framework. >> Perhaps this is a battle worth fighting though and I agree that the >> framework should have a built-in, low resource impact way of dealing with >> 404s. >> >> Kalle >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org >
