He's not suggesting going stateless. He's suggesting an alternate way of maintaining state (by pushing it to the client in hidden fields). Tapestry supports (or supported) this as an option, but it made for some pretty gnarly URLs (all the state had to be appended to the end) for links. On forms, though, it wasn't that bad. The user never knew it. To use this methodology effectively, I believe you have to go into the "everything is a POST" land. Of course, I guess you could get creative with redirect-after-post and using "flash" memory.
On Wed, Nov 19, 2008 at 10:01 AM, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > No worries - you're right - Wicket is designed to manage state for you, so > it's strength is not statelessness. But, you should really evaluate if you > have the need for stateless before constraining yourself to it. As long as > you use models correctly, you can support thousands of concurrent sessions > on a server simultaneously, and you can use the strength of Wicket - letting > it handle state for you. > > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Wed, Nov 19, 2008 at 8:57 AM, Casper Bang <[EMAIL PROTECTED]> wrote: > >> >> Ok. It sounds like the general philosophy behind Wicket is server side >> statefulness. I was kind of hoping this was not the case. Just out of >> curiosity, haven't anyone tried serializing and embedding state out on the >> webpage that could then be POST'ed between requests - a kind of hybrid >> model >> between session and request scope? This homemade hybrid seems to work for >> JSF, though oddly not an official strategy. >> >> I actually just joined the mailinglist and posted, after not seeing my >> message show up after 24h I tried posting again - this time it worked. I >> apologize, now posting via Napple - latency and behavior somewhat more >> deterministic. >> >> /Casper >> >> >> Jeremy Thomerson-5 wrote: >> > >> > Tip: don't double post or some people will jump on you - it doesn't help >> > you >> > get a good answer. >> > >> > Anyway, for completely stateless page transitions, etc, and how to put >> > data >> > into the URL rather than session, you need to use BookmarkablePageLink, >> > which will invoke the YourPage(PageParameters) constructor. Give those a >> > shot. For forms that put their data in the URL, search the list on >> > nabble >> > - there's been two threads this week dealing with it. Basically, mount a >> > bookmarkable page, don't use a Wicket form, just use an HTML form, and >> > make >> > it do a "GET" to the bookmarkable page URL. You can then use the >> > YourPage(PageParameters) constructor again. >> > >> > -- >> > Jeremy Thomerson >> > http://www.wickettraining.com >> > >> > On Wed, Nov 19, 2008 at 6:30 AM, <[EMAIL PROTECTED]> wrote: >> > >> >> Pardon the (possible stupid) question, I'm new to Wicket but is quite >> >> excited about the simplicity it seems to promote over JSF. >> >> >> >> What's the usual way of pushing context on to a website and have it >> >> passed >> >> along, such as to remain stateless? In JSF you would typically create a >> >> request scoped backing bean and create some hidden inputs on the >> webpages >> >> which can hold relevant id's or even base64 encoded and encrypted model >> >> data. I thought perhaps Wicket were able to do this transparantly, as >> >> suggested by the following example: >> >> >> >> // LetterChoice.java >> >> final List<String> someLetters = Arrays.asList("A", "D", "C"); >> >> final DropDownChoice letter = new DropDownChoice("letter", new >> >> Model<String>(), someLetters); >> >> >> >> StatelessForm form = new StatelessForm("keyForm") { >> >> @Override >> >> protected void onSubmit() { >> >> setResponsePage( new LetterResult( someLetters, >> >> Integer.parseInt( letter.getValue() ) ) ); >> >> } >> >> }; >> >> >> >> // LetterResult.java >> >> public LetterResult(List<String> someLetters, int letterId) { >> >> String selectedLetter = someLetters.get( letterId ); >> >> } >> >> >> >> It appears you can pass both the model as well as the selection on to a >> >> new page, but there's no special/hidden content in the generated >> >> LetterChoice webpage. Does this simply mean what I am doing i tied to my >> >> session by Wicket? Is there a way ensure there's no (or just a bare >> >> minimum) of session state between each request? In general, what is the >> >> mission goal when it comes to statefullness/statelessness of Wicket? >> >> >> >> Thanks in advance, >> >> Casper >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20581578.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> 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]
