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
