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
submi
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...
> Will wicket always work in this mode? Is this configurable?
Read: http://cwiki.apache.org/WICKET/render-strategies.html
> Ano
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
yess the rendering strategy is configurable. But do you really want to
resubmit always?
i already told you when a page is created or
reused. Its .created once (bookmarkable or by your sellf
setResponsePage(ne MyPage());) then with a form submit it will reuse
that instance from the session
On 3/2
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 y
You forget the redirect after post, or even when nothing is submitted.
First render of the page refresh...
Martijn
On 3/29/07, Carlos Pita <[EMAIL PROTECTED]> wrote:
>
>
>
> > 3) refresh of the page (is a get, press f5 in your browser)
>
> (1) and (2) were intended to be states where a reloa
3) refresh of the page (is a get, press f5 in your browser)
(1) and (2) were intended to be states where a reload could be attempted.
There is no point in adding a third explicit refresh item. But anyway, not
only f5 but C-R and View/Reload (I'm using firefox) do a reload, which
consists of repe
3) refresh of the page (is a get, press f5 in your browser)
Martijn
On 3/29/07, Carlos Pita <[EMAIL PROTECTED]> wrote:
> > Only if the request was from a form and when you are not using the
> > render-to-buffer strategy.
>
> Sorry Eelco, would you be so kind as to explain this, I'm new to wicket
if you do a submit and validation erros happening then no new pag is
created but the page is reused. but you dont have a problem then
because the form will have all the values posted.But if the user does
a refresh then in default wicket setting, you dont do a new post, one
a page request to the cur
Only if the request was from a form and when you are not using the
render-to-buffer strategy.
Sorry Eelco, would you be so kind as to explain this, I'm new to wicket and
still a bit ignorant of its internals.
I see two access points to the form page:
1) First time you enter the page.
2) Resubmis
> > and if a user just refreshes the page? or you use it as a response
> > page somewhere else? then suddenly everything is empty?
>
> If the user refreshes the page the previous request parameters will be
> reposted and will overwrite the fresh form model object properties, so he
> will see the pa
and if a user just refreshes the page? or you use it as a response
page somewhere else? then suddenly everything is empty?
If the user refreshes the page the previous request parameters will be
reposted and will overwrite the fresh form model object properties, so he
will see the page as was b
On 3/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> and if a user just refreshes the page? or you use it as a response
> page somewhere else? then suddenly everything is empty?
Yeah, that's a good point.
Eelco
-
Take Su
and if a user just refreshes the page? or you use it as a response
page somewhere else? then suddenly everything is empty?
On 3/29/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > One problem I have due to avoiding DTOs is that most of the time I don't
> > want to serialize my form models, becau
class SomeModel extends LoadableDetachableModel {
protected Object load() {
return new Foo();
}
}
new SomeModel(anotherFooThatWasLoaded);
Oh, cute! Or even:
new LoadableDetachableModel(anotherFooThatWasLoaded) {
protected Object load() { return new Foo(); }
}
I thought that l
> One problem I have due to avoiding DTOs is that most of the time I don't
> want to serialize my form models, because they are (often big) entities with
> lazy loaded associations. So in principle I would use an
> LoadableDetachableModel to load the entity from the repository each time the
> model
Also, how are you going to resolve the relations? Person -> Address?
> Are you going to create those as well?
Exactly. It's the thing most people do with spring-mvc I guess. There your
request parameters are bound to fresh objects by default (although you could
override formBackingObject() to c
Hi Martijn,
Not all values will be overwritten, and if you don't check for
concurrent updates (your users will try to modify the same object at
the same time!) you are in for some hefty support calls.
Concurrent updates won't be common because most of the updated info will be
per user, and on
Not all values will be overwritten, and if you don't check for
concurrent updates (your users will try to modify the same object at
the same time!) you are in for some hefty support calls.
And if you disable a field, its value will not be part of the form
processing, also something to take into co
19 matches
Mail list logo
