For anyone who is interested (new users) the appropriate resource is here:
http://cwiki.apache.org/WICKET/request-processing-overview.html WicketKeeper wrote: > > Thanks for prompt reply. > > Yes, I was thinking having 1 DataConn for every new request. So what i > envision is: > 1. User goes to home page ("active window" being the browser window) > 2. On connection, a new DataConn object should be initialised. > 3. User does data enquiry stuff from that page (lots of tabs, form inputs > etc.) - components on the page are populated by making requests to > DataConn. > > Otherwise I could have just 1 DataConn for the entire application but it > might get a bit loaded if there are lots and lots of people connecting - > plus it does user authentication via the contructor so there has to be 1 > DataConn per user. > > Thanks for your help so far! > WK > > > Johan Compagner wrote: >> >> opening a DataConn everytime for every request isn't really what you want >> i >> guess? >> (else you could have a custom request cycle that does this) >> >> But what you could do is hold an transient field in your custom Wicket >> Session object >> and maybe besides that a id or description so that you can restore that >> transient field. >> And keep in in the session as long as possible. But it could be that the >> field (the dataconn) >> is sometimes null if the wicket sessions was serialized by the container. >> >> What do you mean active window? What is the active window? >> Do you want an datacon object per browser window? >> You could look if you can have 1 per pagemap then >> >> >> johan >> >> >> On 10/25/07, WicketKeeper <[EMAIL PROTECTED]> wrote: >>> >>> >>> Hi >>> Thanks... >>> Then how do I get that object by it's id? (did you mean component id?) >>> >>> I guess what i'm asking is how to best structure things in Wicket when >>> there >>> is a resource that isn't serializable and is used by multiple >>> components. >>> >>> So in my case I have a number of tabs, each with its own panel. Within >>> the >>> panel there's a bunch of fillable components, e.g. tables, which are >>> populated by using DataConn. However for every person that visits the >>> site >>> there can only ever be one instance of DataConn (so there would be >>> multiple >>> instances in the application if more then one person is hitting the home >>> page). >>> >>> Another question: DataConn should also be "wrapped up" so that GB can >>> deal >>> with it once a user closes the active window. Is there a way to do this? >>> >>> I keep coming back to the idea of Sessions here but I have a gap in my >>> understanding of how wicket is deploying objects here. Any help, much >>> appreciated. >>> >>> Thanks! >>> WW. >>> >>> >>> >>> Johan Compagner wrote: >>> > >>> > you can't keep hard (must be transient) references to those resources >>> > so you always should be able to look it up again. by, for example, >>> some >>> id >>> > that isn't transient >>> > >>> > johan >>> > >>> > >>> > >>> > On 10/24/07, WicketKeeper <[EMAIL PROTECTED]> wrote: >>> >> >>> >> >>> >> Hi >>> >> >>> >> I'm new to Wicket to this might be an ultra-dum question :) >>> >> >>> >> I'm creating a wicket application that gets its data from an online >>> >> resource. The connection logic to that resource is in an external jar >>> and >>> >> most of those classes don't implement Serializable. Fore ease of >>> >> explanation, let's call the entry class for the connection >>> "DataConn". >>> So >>> >> whenever I want to get specific data to, say, fill in an >>> >> AutoCompleteTextField all i do is list=dataconn.getStuff(). >>> >> >>> >> Moreover, whenever someone comes to the application's homepage they >>> >> shoult >>> >> only ever have ONE instance of DataConn, i.e. 1 instance for each >>> "user". >>> >> >>> >> So my question is - what's the best way to go about doing this in >>> Wicket? >>> >> I >>> >> am aware of Session and Models in wicket (though my understanding is >>> >> poor) >>> >> - >>> >> could anyone direct me to the appropriate examples or suggestions >>> please? >>> >> >>> >> Thanks >>> >> WK. >>> >> -- >>> >> View this message in context: >>> >> >>> http://www.nabble.com/Non-serializable-objects-and-efficiency-tf4684047.html#a13384755 >>> >> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> >> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >>> >> >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Non-serializable-objects-and-efficiency-tf4684047.html#a13401731 >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Non-serializable-objects-and-efficiency-tf4684047.html#a13507269 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
