agree that this cannot be /the/ solution.
but, i think we ought to take the same general approach to backbutton/undo as we just did with clustering and Sessions....
we want a brain-dead-simple way to start (like component change and model cloning via serialization) which aids rapid development, prototypes and small scale problems.
then we want hooks that allow people to optimize things as much as they care to.
this way you can start with something easy that eats cpu and memory and then tune the parts that really matter.
so i think your cloning idea is probably at least a small part of the solution, if only because it will help the bottom end of our scaling story... an easy entrypoint.
jon
Johan Compagner wrote:
We already have an implementation for a deep clone but this is much to cpu and memory intensive..
It works but ....
Jonathan Locke wrote:
i still don't see what this has to do with client side state. it seems like that's a separate issue.
it looks like the thing that needs to be done is deep cloning the model as part of undo state recording...
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:
any actionHi,
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
(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
------------------------------------------------------- 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
