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#a13402917
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
