ahh you need to have my first mail (did send it on 4-3!)
You know i am thinking about fixen the stale pages as much as possible 2 things can be changed:
1> components (removeAll/replace) 2> model data.
components i think i can fix with a undoable support. Where i can replace/set back the components that where removed.
model data is different the example i gave was this:
I have one page where i edit some data. Let's say a workflow item that is queried somehow from somewhere.
I have a save button on that form. And when i press save the workflow item is saved and the next one is set into the model
When a user is then going to the back button because suddenly he thought, ahh made some mistake in the entry
Then he sees the screen of the previous workflow item. When he then changes something and presses save. We have a problem
Because if the page is not stale it will save the previous workflow item over the one that was currently in the model. (the second one)
that one gets saved and the third one is get from somewhere and stored in the model for display.
So thats why we need some light as possible state support into the client. I want this as light as possible of course
so that we can recreate the data that was in the model at the moment it rendered that screen.
johan
Jonathan Locke wrote:
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
