about 4>
I never want it to be an error
a user must be able to go back to a page with a model object he just
editted and re submit it again
with some changes he just forget.
The page can never be stale for such an example.
Please read my example carefully. This must be supported in any webapp
i want to make
there must be some state kept in the browser or as jonathan says a
complete copy/clone of the model.
But that i already implemented but was rejected by most developers. For
all the examples we have here
that approache did work yes. But i know this copy by serialization
takes to much resources (cpu and memory)
You never be able to do a undo of the model data without getting some
data somewhere
We as wicket (the framework) don't know nothing about the models and
there data. So without cloning/copying
we can't do anything i believe.
But give a model some extra methods so that we can get data, for
rendering a link (in the url) or form (as hidden field)
and then set that back so that the user can restore it previous state
of the model where the rendering of that page did take place.
But if anybody has better idea's please do make suggestions. In the end
it is this:
After rendering the current component/model object of wicket should be
'locked'
So if a request comes back from a page in rendering number X it should
return to that locked stage.
johan
Gili wrote:
But we already have a page reference number already in place
that tracks the current Page referenced by the user. You are right that
we need extra data on the client side to track this (i.e. encode it as
part of the URL), but we don't need a 36 digit unique ID for that. We
just sequentially increment the page number as we're already doing. If
the user goes back and edits some model element that has been removed,
what I think should happen is:
1) Server detects the user moved back to a previous page because the
client page and server page numbers are not equal
2) Server invokes UndoableEdits until the server and client pages are
equal
3) Server handles the user request as usual.
4) Model detects that the user referenced an invalid element and throws
an error. This should occur regardless of whether the user hits the
Back key and makes this mistakes or tries "hacking" the server by
modifying the URL directly. The bottom line is that this isn't (in my
view) a "back button issue". It is a normal issue any normal webapp
should be designed to handle -- basic validation routines.
Gili
On Mon, 7 Mar 2005 20:01:21 +0100, 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
|
