Thank you very much Martijn and Eelco, I won't say you made it crystal clear
to me now, but I understand a tad more. I would now reformulate my (1) and
(2) states as:
(1) The form is entered from a bookmarkable page.
(2) The form is posted (POST) to a non-bookmarkable page because of normal
submission.
and a new one:
(3) The pre-rendered buffer is gotten (GET) from a reload, back/forward or
history (assuming REDIRECT_TO_BUFFER).
Suppose we use a LoadableDetachableModel as the one suggested by Eelco
before.
A new form is created in (1), so a new model is created too. As this is the
first time its model object is accessed, an entity from the repository will
be returned. The page populated with this model object will be rendered and
stored into the buffer.
The same form is reutilized in (2). As this isn't the first time its model
is asked for its object it will return a brand new object. The page
populated with this blank model object overwritten from the POST request
parameters will again be rendered and stored into the buffer.
Because we are using the redirect after post pattern what we get after a
reload will be the buffered page which has been rendered from the right
model object in each case. I don't know how many buffers will be pooled, or
the way they are identified, but assuming an ideal* 1-1 mapping between
buffers and requests, I can't see the problem for the other cases:
back/forward and history. Ok, because of redirect-after-post we won't be
resubmitting the form every time as I thought at first, that's clear, but
because of redirect-to-buffer we won't be rerendering it either. That would
be another history for redirect-to-render because in that case the
connection between the original request and the current state is lost.
* maybe the problem is in this assumption, isn't it?
Thank you again.
Regards,
Carlos
On 3/29/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 3/29/07, Carlos Pita <[EMAIL PROTECTED]> wrote:
>
>
> > You forget the redirect after post, or even when nothing is submitted.
> > First render of the page.... refresh...
>
> I have been reading about the redirect after post pattern (of which I
wasn't
> aware) here
> http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost
> and now I understand your point.
> Will wicket always work in this mode? Is this configurable?
It is configurable. Read up in IRequestCycleSettings#RenderStrategy
(ONE_PASS_RENDER, REDIRECT_TO_RENDER or the default
REDIRECT_TO_BUFFER).
> Another thing that I asked before in this thread and of which I'm still
not
> sure is about page creation. When will pages be created? Every time they
are
> accessed or just the first and then serialized into the session?
Bookmarkable pages accessed by their bookmarkable URLs will be created
every time. Everything else is created when you do, and then kept in
memory for later use. Depending on the session store (ISessionStore)
implementation you are using, they may be serialized only to be
de-serialized when users push the back button and the version they
want cannot be found anymore in memory. Otherwise, just the instance
as you put it there will be used. Note 'detachement' though.
Components and models are detached at the end of requests to enable
you to clean up temporary state and possibly optimize the ammount of
memory that is needed for the long term.
> This is
> relevant to form model management because if my model discriminates
between
> the first time the form is entered and other times (for example after
> resubmission), things won't work as expected if the model is
instantiated
> just once along the entire session (instead of once every time I enter
the
> form page for a new, say UserProfile, update).
So, you cannot depend on the model being created on every request.
However, you can depend on your model being detached on the end of a
request, and if you combine that with lazily attaching like
LoadableDetachableModel does (easy to implement yourself too), you can
achieve the same thing as if you would have the models recreated on
every request.
Eelco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
