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
