Maybe if you replace "users's silo" with "user location" and then say Example, if location="silo"... things will be a little less bound to your use case... Otherwise your description of what you want to achieve looks fine fine to me... but I'm no core developer... So, why not wait to see what do they comment on this issue?
Best, Ernesto On Mon, Dec 28, 2009 at 1:44 PM, Martin Makundi < [email protected]> wrote: > How would you formulate such RFE? > > "Wicket needs an autonomus but parametrizable global behavior, that is > transparent to all url encoding schemes, that can be used to identify > users's silo in the application. When session is invalidated or other > errors occur, each silo can have its own errorpage/homepage which is > automatically rendered by the behavior." > > Is this descriptive enough? > > Maybe some junit wickettester test cases? > - "test 1: User has begun using Silo1Homepage.class when session is > invalidated. User is redirected back to Silo1Homepage." > - "test 2: User has begun using Silo2Homepage.class when session is > invalidated. User is redirected back to Silo2Homepage." > - similar for error pages, and after error page -> silo-home-page > - etc. > > ** > Martin > > > 2009/12/28 Ernesto Reinaldo Barreiro <[email protected]>: > > Create a RFE? Maybe on 1.5 it is already possible? > > > > Ernesto > > > > On Mon, Dec 28, 2009 at 1:16 PM, Martin Makundi < > > [email protected]> wrote: > > > >> It should be automatic and global, like a url encoding scheme, and it > >> should come with an interpreter that will process the > >> homepage/errorpage when necessary. > >> > >> ** > >> Martin > >> > >> 2009/12/28 Ernesto Reinaldo Barreiro <[email protected]>: > >> >> > >> >> > >> >> But where could we bind the silo information into urls globally? > >> >> > >> >> > >> > Mounting pages? Or better having some kind of configuration class that > >> you > >> > use to mount the pages and do the ugly URL plumbing on that method? > >> > > >> > Best, > >> > > >> > Ernesto > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
