I guess wicketsessions will be different. I know I proposed to do that but not sure is the best solution. I your case I would surelly opt for the solution you have in place right now.
Ernesto On Mon, Dec 28, 2009 at 4:09 PM, Martin Makundi < [email protected]> wrote: > Might work, but I do not know if it has any consequences such as will > the user have a single wicketsession? > > ** > Martin > > 2009/12/28 Jim Pinkham <[email protected]>: > > I think this suggestion is worth condsidering more carefully: > > > >>> Can you just achieve what you wan't making siloA, siloB, siloC been > >>> different "Wicket" applications? > > > >>No, that is not the proper solution. They are the same application. > > > > OK, but could you deploy multiple copies of the same app to different > root > > contexts - that would give you the info you want in each URL and thus be > > able to do different home/error pages with some config along with each > copy > > of the app. Seems worth exploring whether your Silos might divide well > in > > this manner, maybe with a bit of work, but probably more likely to happen > > than what it seems like you are looking for, which doesn't sound (just > one > > casual observer's option) broadly applicable enough to warrant framework > > inclusion. > > > > Good luck > > Jim P > > On Mon, Dec 28, 2009 at 8:04 AM, Martin Makundi < > > [email protected]> wrote: > > > >> 2009/12/28 Ernesto Reinaldo Barreiro <[email protected]>: > >> > but I'm no core developer... So, why not wait to see what > >> > do they comment on this issue? > >> > >> Maybe they just want us to weather this out on ourselves ... ;) > >> > >> ** > >> Martin > >> > >> > > >> > 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] > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> 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] > >
