why dont they survive? i didnt mean that you should store the actual receiver objects into the hashmap just the properties and there values
johan On Mon, Sep 8, 2008 at 2:32 PM, Lutz Müller <[EMAIL PROTECTED]> wrote: > yes, what i did is simply attaching a hashmap to my session where i keep > the objects while the user edits them in a page. of course they do not > survive session serialization this way, but it works for now. > > On Monday 08 September 2008 14:11:54 you wrote: > > > if your domain objects are not serializeable then there is no other > > > solution then to have > > > a copy or a hashmap that holds those things in mem for a few requests. > > > > > > johan > > > > > > On Mon, Sep 8, 2008 at 1:33 PM, Lutz Müller <[EMAIL PROTECTED]> > wrote: > > > > On Sunday 07 September 2008 00:00:15 Johan Compagner wrote: > > > > > Use loadabledetacheable models for those objects, in the load method > > > > > call the service method to get your bus. object back > > > > > > > > However , there is a problem if you use loadabledetachable with AJAX > > > > requests > > > > on your page. Model.detach() is called on every request, which causes > > > > your object to be retrieved from database on the next Model.getObject() > > > > call. This > > > > means you lose all changes on your bound domain obect on every ajax > > > > request. > > > > I found to solutions to this, and i like neither of them: > > > > > > > > a) use DTOs, which means a lot of code duplication. > > > > > > > > b) write the current object state to the database on every detach, > which > > > > means you might store objects in an incomplete state, before the user > > > > explicitly tells the application to store what she or hehas entered. > > > > > > > > If anybody has a nicer solution to this, i'd love to hear about it. > > > > > > > > > On 9/6/08, FakeBoy <[EMAIL PROTECTED]> wrote: > > > > > > Hello all, > > > > > > I am thinking about the best design architecture for public web > > > > > > > > project. > > > > > > > > > > I used to work with classic 3 tier architecture: > > > > > > 1. tier - tier of business logic (business domain obejcts) > > > > > > 2. tier - middle service tier or API to business logic (EJB, > Spring, > > > > > > =>convert business object to DTO - Data Transfer Object) > > > > > > 3. tier - client tier (Wicket) > > > > > > A used to make distributed application where client side was not on > > > > > > the same virtual machine as middle tier, so copying from business > > > > > > model to DTO and back had purpose (reduce complexity of business > > > > > > obejct with > > > > > > > > many > > > > > > > > > > relationships, reduce traffic and it also solved the problem with > > > > > > serialization of business obejct - RMI). > > > > > > But now I am programming web application in which all these 3 > layers > > > > > > > > will > > > > > > > > > > be placed in the same Virtual machine. So now It seems to be > > > > > > pointless > > > > > > > > to > > > > > > > > > > convert/copy business obejct to DTO and back. So I would like to > use > > > > > > business objects directly in client layer. Middle layer will be > still > > > > > > > > in > > > > > > > > > > my app, but all service method will be return business objects > > > > > > directly instead of DTO. > > > > > > Now I am thinking abou problems that I will face to. > > > > > > 1. Some business object are not serializable - I tried to made some > > > > > > simple examples (ListPage, FormPage), and some little problem I > > > > > > > > overcome, > > > > > > > > > > but I must made my custom Model => TransientModel, PropertyModel => > > > > > > TransientPropertyModel etc. > > > > > > > > > > > > Can you help me to define some others problems that can make me a > lot > > > > > > > > of > > > > > > > > > > troubles or try to give me your ideas and experiences with this > > > > > > issue. > > > > > > > > > > > > Thanks a lot once again. > > > > > > Dave > > > > > > > > > > > > -- > > > > > > View this message in context: > > > > > > > > > http://www.nabble.com/Wicket---No-Serializable-objects-Web-application-tp > > > > > > > > > >19351608p19351608.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] > >
