We tried that once, to have state transfered to the client, we didnt like it (where it did go to) and we dropped it. Cpu time and bandtwidth is way more expensive then memory. Wicket takes now memory on the server but the overhead it would generate by serializing and base64 every page into the result and the other way around is just way way to expensive.
Did you encounter any real issues with state on the server or is this again premature optimization?? On 11/19/08, 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]
