It might be good to try to ask specific questions about those issues that you've seen. You will get good help here on the list, and from my experience, you won't get a much better / simpler programming model than what Wicket gives you. I've used Tapestry, where everything was stuffed into the urls and it was a nightmare creating truly reusable components that could be used anywhere. With Wicket, it's just not that way.
Anyway, your use case sounds intriguing - what issues are you seeing? Probably something simple that you could do different - must simpler than managing state yourself. On Wed, Nov 19, 2008 at 10:58 AM, Casper Bang <[EMAIL PROTECTED]> wrote: > > Yes we've experienced issues with multiple browser windows as well as > synchronization of shared session resources. Again, this has nothing to do > with optimization but everything to do with craving a solid, simple > programming model for frontend developers. > > /Casper > > > > Johan Compagner wrote: > > > > 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] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Noob-question%3A-Wicket-and-statefull-stateless-tp20578870p20584228.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] > > -- Jeremy Thomerson http://www.wickettraining.com
