Hi, > it looks like the thing that needs to be done is deep cloning > the model as part of undo state recording...
That can be very hard to implement on models: -auto cloning by serialization is expensive on server. -copy constructor is annoying for the developer. -not sure about clonable? -more memory usage on the server by keeping all the modelobjects for each modelobject change/renderphase. So that's why I suggested handling the correct model object instance via an unique id which the developer can choose to implement as he likes (one possible scenario is guid/uuid) Jan > Jan Blok wrote: > > >Hi, > > > > > > > >>the main problem is that i don't understand (and johan > >>probably posted > >>this but i don't have it)... exactly what problem are we > >>trying to solve here? > >> > >> > > > >Johan was explaining the problems with the browser "back" > button, in for > >example a workflow application where the user has to process > 5 records > >which are rendered to him one after another, by replacing the > >model(object) in a component on the server. At a certain point he > >decides to go back to fill-in something he missed, when he > now submits > >the page to the server there is a browser-to-model out of > sync problem, > >which can be solved by attaching an uuid to each model and rendering > >this to the browser > > > >Another problem I can imagion is a user deleting a list > item, going back > >with back button, submit a change, now he edits unknowingliy the item > >after the deleted item, this also can be detected by an uuid > > > >So im suggesting a "hard" link between a rendered output and server > >model object instance..., by means of a uuid which the > developer "can" > >choose to use in his model implementation. (instead of the current > >component name binding only, thus without binding on the > component model > >object instance) > > > >Regards Jan Blok > > > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf > >>Of Jonathan Locke > >>Sent: Monday, March 07, 2005 6:52 PM > >>To: [email protected] > >>Subject: Re: [Wicket-develop] More Model suggestions, was > >>"backbutton problem" > >> > >> > >> > >>with this wacky email server on sourceforge i have your > >>response but not > >>johan's original post! > >> > >>DetachableModel was replaced by AbstractDetachableModel, which is > >>designed for anonymous subclassing. > >> > >>yes, a UUID ought to be a low security risk in most cases and > >>would be > >>less of a performance problem than other options for client > >>side state. > >> > >>however, i think AbstractDetachableModel is useful in its own > >>right and > >>that we ought to keep it as-is. > >> > >>i'm having trouble with your sketch below for several > reasons i can't > >>quite articulate yet... > >> > >>the main problem is that i don't understand (and johan > >>probably posted > >>this but i don't have it)... exactly what problem are we > >>trying to solve > >>here? > >> > >>i don't see any real advantage to storing a UUID on the > client if you > >>still have a Page and a model on the server. you haven't > reduced the > >>server state to zero. if you want zero server state, that > is already > >>supported via bookmarkable pages. a bookmarkable page > >>constructs itself > >>entirely from request information. you can stick your UUID in > >>PageParameters and pass that to BookmarkablePageLink and away > >>you go. > >>when the request comes in your page will be created and you can > >>synthesize your page's model and structure based on the abstracted > >>request information in PageParameters. i think this is > >>actually quite > >>elegant and simple in terms of solving the problem of constructing > >>zero-state pages. > >> > >>Jan Blok wrote: > >> > >> > >> > >>>Hi, > >>> > >>> > >>> > >>> > >>> > >>>>somehow we have to have more state loaded into the client > >>>>(but i don't like this, get .NET feelings now...) > >>>>so that the right model can first be created again before > >>>> > >>>> > >>any action > >> > >> > >>>>(form population from the request and the action handling) > >>>>any other ideas? > >>>>johan > >>>> > >>>> > >>>> > >>>> > >>> > >>>I totally agree with Johan, is it an idea to change > >>> > >>> > >>IDetachableModel to? > >> > >> > >>>: > >>> > >>>public interface IDetachableModel extends IModel > >>>{ > >>> public String getUUID();//max length 36 chars, limit this to > >>>prevent flooding the page like .NET > >>> > >>> public void attach(String uuid); > >>> > >>> public void detach(); > >>>} > >>> > >>>Hmm, IDetachableModel is changed to IDetachable? Recently? > >>> > >>>If you pass the uuid into the pagereponse (forms/links) if > the model > >>>returns one, it can be used to lookup the correct modelstate at all > >>>times. > >>> > >>>Max length 36 is for a GUID alike thing like: > >>>10030100-E260-11CF-AE68-00AA004A34D5 so you can address any > >>> > >>> > >>molecule in > >> > >> > >>>the universe :-), instead of a GUID you could use a uuid like > >>>"orders_23461567" for specific hibernate "order" object. > >>>By keeping the length limited you also prevent HTTP-POST > req. as .NET > >>>has for any action. > >>> > >>>Regards Jan Blok > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>SF email is sponsored by - The IT Product Guide > >>>Read honest & candid reviews on hundreds of IT Products from > >>> > >>> > >>real users. > >> > >> > >>>Discover which products truly live up to the hype. Start > reading now. > >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>>_______________________________________________ > >>>Wicket-develop mailing list > >>>[email protected] > >>>https://lists.sourceforge.net/lists/listinfo/wicket-develop > >>> > >>> > >>> > >>> > >>> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from > >>real users. > >>Discover which products truly live up to the hype. Start > reading now. > >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>_______________________________________________ > >>Wicket-develop mailing list > >>[email protected] > >>https://lists.sourceforge.net/lists/listinfo/wicket-develop > >> > >> > >> > > > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from > real users. > >Discover which products truly live up to the hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >_______________________________________________ > >Wicket-develop mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
