In my projects I've taken this to the extreme of not allowing Index pages to have a context and enforcing this rule with some code. My workaround is to trick the PageRenderDispatcher to skip Index pages and then adding a new Dispatcher (to the end of the pipeline) that forces EMPTY_CONTEXT on all the Index pages.
Here is the module: https://gist.github.com/3360101 BTW, we talked about this like few months ago: http://tapestry.1045711.n5.nabble.com/No-404-error-is-raised-td3212773.html -- Alejandro. On Mon, Jan 28, 2013 at 10:42 AM, Taha Siddiqi <tawus.tapes...@gmail.com> wrote: > 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
