I'm reading your example and I still don't understand you need
anything client-side for this. Why do you need to store anything on the
client end to undo the model state? The only thing I expect to see on
the client end is the session ID (which the servlet specification takes
care of for you) and everything else is server-end. What am I missing?

Gili

On Mon, 07 Mar 2005 19:31:58 +0100, Johan Compagner wrote:

>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
>




-------------------------------------------------------
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

Reply via email to