Re: [Wicket-user] Binding and validating domain objects
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 consideration. Hibernate and JPA use optimistic locking by introducing a version field. The first person to save the update 'wins'. The second will not be able to update (the version has been upped, effectively changing the logical key for the object, so the update will not find the record). This version can be stored in your model or even in your form [1]. Also, how are you going to resolve the relations? Person - Address? Are you going to create those as well? I think your approach is novel, but may need some thorough thinking. Martijn [1] http://martijndashorst.com/blog/2006/02/13/wicket-goodie-hibernate-versioned-form/ On 3/29/07, Carlos Pita [EMAIL PROTECTED] wrote: Hi all, I'm migrating a spring-mvc project to wicket. In this project domain objects are directly exposed to the ui (without DTOs in between). The objects are validated using the spring bean validation framework (part of springmodules). This module creates a unique Validator (a spring interface) from annotations given in the fields/properties of every validatable object. Then you inject this global validator to your controllers (in the case of spring-mvc) so they can validate their form/command (the bound object). The result of validation is an Errors objects, with field errors and global errors (more precisely, error codes to be resolved against a messages resource). It's pretty easy to map these errors from bean properties to wicket component ids. This should be done inside onSubmit(), once the object is bound (for example, using a CompoundPropertyModel). So, to recap: domain objects directly exposed to the ui, Validator created from annotations in validatable domain objects, domain objects bound by PropertyModels, domain objects validated by injected validator during onSubmit. Up to this point I'm pretty happy with the results, validation is almost trivial with the annotations and the valang dsl, and I like it being inside the domain instead of tied to the ui components. 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 is reattached. But suppose I'm updating a UserProfile. The first time it would be ok to populate the model from the persistent profile to be updated. But once the form is submitted there's no point in loading the profile from the repository again because its properties would be overwritten from those coming from the form anyway. So I'm tempted to subclass AbstractDetachableModel so that it loads the profile from the repository upon creation, but instantiates a brand new profile to be populated from the form upon reattachment. Is there a better pattern for this? Anyone has run into the same problem? Cheers, Carlos - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 only one session could be opened per user. Anyway, in case they do happen, I will use optimistic or pessimistic locking depending on the particular scenario (most often pessimistic because concurrent editings won't be frequent); and it's not always that I care about application-level transactionality: you and me can start editing A, then you commit A', then I commit A'', not serializable behaviour, but it would acceptable sometimes. And if you disable a field, its value will not be part of the form processing, also something to take into consideration. Yep, in this case I would use LoadableDetachableModel to load the entity every time. But it's not that often that my forms show just fragments of the entire entity. I'm not proposing/asking for a one-size-fits-all solution, just one that fits a use case like that described for the UserProfile. 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 change that). The associated objects are created in albis during construction of the main one, and so on recursively. Binding is then done up to arbitrary nesting levels. Regards, Carlos Martijn [1] http://martijndashorst.com/blog/2006/02/13/wicket-goodie-hibernate-versioned-form/ On 3/29/07, Carlos Pita [EMAIL PROTECTED] wrote: Hi all, I'm migrating a spring-mvc project to wicket. In this project domain objects are directly exposed to the ui (without DTOs in between). The objects are validated using the spring bean validation framework (part of springmodules). This module creates a unique Validator (a spring interface) from annotations given in the fields/properties of every validatable object. Then you inject this global validator to your controllers (in the case of spring-mvc) so they can validate their form/command (the bound object). The result of validation is an Errors objects, with field errors and global errors (more precisely, error codes to be resolved against a messages resource). It's pretty easy to map these errors from bean properties to wicket component ids. This should be done inside onSubmit(), once the object is bound (for example, using a CompoundPropertyModel). So, to recap: domain objects directly exposed to the ui, Validator created from annotations in validatable domain objects, domain objects bound by PropertyModels, domain objects validated by injected validator during onSubmit. Up to this point I'm pretty happy with the results, validation is almost trivial with the annotations and the valang dsl, and I like it being inside the domain instead of tied to the ui components. 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 is reattached. But suppose I'm updating a UserProfile. The first time it would be ok to populate the model from the persistent profile to be updated. But once the form is submitted there's no point in loading the profile from the repository again because its properties would be overwritten from those coming from the form anyway. So I'm tempted to subclass AbstractDetachableModel so that it loads the profile from the repository upon creation, but instantiates a brand new profile to be populated from the form upon reattachment. Is there a better pattern for this? Anyone has run into the same problem? Cheers, Carlos - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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
Re: [Wicket-user] Binding and validating domain objects
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 change that). The associated objects are created in albis during construction of the main one, and so on recursively. Binding is then done up to arbitrary nesting levels. To state this more precisely: relationships that are more of a component kind (and that will possibly be stored as dependants along the same table as the main entity) will be created in blank (of course, assuming you're in fact editing them from the form); combo-like stuff will be brought back from the database from id each time. I was doing the second using entity--id PropertyEditors in spring-mvc, still don't know how to get the same with wicket but I suppose it won't be hard. Regards, Carlos Martijn [1] http://martijndashorst.com/blog/2006/02/13/wicket-goodie-hibernate-versioned-form/ On 3/29/07, Carlos Pita [EMAIL PROTECTED] wrote: Hi all, I'm migrating a spring-mvc project to wicket. In this project domain objects are directly exposed to the ui (without DTOs in between). The objects are validated using the spring bean validation framework (part of springmodules). This module creates a unique Validator (a spring interface) from annotations given in the fields/properties of every validatable object. Then you inject this global validator to your controllers (in the case of spring-mvc) so they can validate their form/command (the bound object). The result of validation is an Errors objects, with field errors and global errors (more precisely, error codes to be resolved against a messages resource). It's pretty easy to map these errors from bean properties to wicket component ids. This should be done inside onSubmit(), once the object is bound (for example, using a CompoundPropertyModel). So, to recap: domain objects directly exposed to the ui, Validator created from annotations in validatable domain objects, domain objects bound by PropertyModels, domain objects validated by injected validator during onSubmit. Up to this point I'm pretty happy with the results, validation is almost trivial with the annotations and the valang dsl, and I like it being inside the domain instead of tied to the ui components. 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 is reattached. But suppose I'm updating a UserProfile. The first time it would be ok to populate the model from the persistent profile to be updated. But once the form is submitted there's no point in loading the profile from the repository again because its properties would be overwritten from those coming from the form anyway. So I'm tempted to subclass AbstractDetachableModel so that it loads the profile from the repository upon creation, but instantiates a brand new profile to be populated from the form upon reattachment. Is there a better pattern for this? Anyone has run into the same problem? Cheers, Carlos - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=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
Re: [Wicket-user] Binding and validating domain objects
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 is reattached. But suppose I'm updating a UserProfile. The first time
it would be ok to populate the model from the persistent profile to be
updated. But once the form is submitted there's no point in loading the
profile from the repository again because its properties would be
overwritten from those coming from the form anyway. So I'm tempted to
subclass AbstractDetachableModel so that it loads the profile from the
repository upon creation, but instantiates a brand new profile to be
populated from the form upon reattachment. Is there a better pattern for
this? Anyone has run into the same problem?
Sounds like that could work. Btw, you can still just use
LoadableDetachableModels. Something like this?
class SomeModel extends LoadableDetachableModel {
protected Object load() {
return new Foo();
}
}
new SomeModel(anotherFooThatWasLoaded);
The thing I want to point out here is that you can just initialize the
LDM with the object you loaded from the database, for the first
request, and then implement load like this to get fresh instances on
next requests.
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.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 load would be called even the first time.
Regarding validation, I'm feeling a tad too frustrated trying to integrate
the bean validation framework infrastructure.
The problem is that spring validators assume that the bean is already bound.
But in the cases where the bean comes from the repositories (inside a
session-in-view), at the time it has been invalidly bound only an exception
thrown inside a transactional context (for example a @Transactional
annotated service method) could avoid persisting an invalid bean.
So I could make onSubmit transactional itself resorting to some aop arcane,
or I could put the validation inside a service (but then I would face a
nightmare of errors/exceptions mapping), or I could get rid of my beloved
validators and learn to love wicket validators (which are fine except that I
don't like the tight tie that they have with the presentation components). I
could momentarily detach the entity before binding it also, but this is a
nono for entities with complex lazy-loaded associations.
This is the kind of dilemma that I usually solve up not going against the
framework (wicket in this case). But if someone has an idea about how
validation could happen after binding inside a [EMAIL PROTECTED] context
without incurring the risk of persisting an invalid entity, and without
losing the ability to simply map errors to ui components, please let me
know.
Cheers,
Carlos
The thing I want to point out here is that you can just initialize the
LDM with the object you loaded from the database, for the first
request, and then implement load like this to get fresh instances on
next requests.
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 before his last non-submitted changes. That seems
fine to me. What I'm not sure is about what will happen if the first page
(the one previous to any submission) is reloaded. Will wicket reinstantiate
the form so the contents will be correctly reloaded from the repository? Or
will it reuse the form stored in the session whose model will now return a
blank object?
Cheers,
Carlos
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, 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 is reattached. But suppose I'm updating a UserProfile. The first
time
it would be ok to populate the model from the persistent profile to be
updated. But once the form is submitted there's no point in loading
the
profile from the repository again because its properties would be
overwritten from those coming from the form anyway. So I'm tempted to
subclass AbstractDetachableModel so that it loads the profile from the
repository upon creation, but instantiates a brand new profile to be
populated from the form upon reattachment. Is there a better pattern
for
this? Anyone has run into the same problem?
Sounds like that could work. Btw, you can still just use
LoadableDetachableModels. Something like this?
class SomeModel extends LoadableDetachableModel {
protected Object load() {
return new Foo();
}
}
new SomeModel(anotherFooThatWasLoaded);
The thing I want to point out here is that you can just initialize the
LDM with the object you loaded from the database, for the first
request, and then implement load like this to get fresh instances on
next requests.
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 before his last non-submitted changes. Only if the request was from a form and when you are not using the render-to-buffer strategy. 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 current page because we use redirect_after_post (in a special wicket way) 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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 repeating the last request, which could be a post or a get, depending on the method you specify for your form; in any case the form contents will be resubmitted. Of course, this doesn't mean that things will work as I first suggested/asked. Cheers, Carlos 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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 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 repeating the last request, which could be a post or a get, depending on the method you specify for your form; in any case the form contents will be resubmitted. Of course, this doesn't mean that things will work as I first suggested/asked. Cheers, Carlos 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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
Re: [Wicket-user] Binding and validating domain objects
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? 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? 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). Cheers, Carlos 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 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 repeating the last request, which could be a post or a get, depending on the method you specify for your form; in any case the form contents will be resubmitted. Of course, this doesn't mean that things will work as I first suggested/asked. Cheers, Carlos 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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=DEVDEV ___
Re: [Wicket-user] Binding and validating domain objects
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/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? 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? 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). Cheers, Carlos 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 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 repeating the last request, which could be a post or a get, depending on the method you specify for your form; in any case the form contents will be resubmitted. Of course, this doesn't mean that things will work as I first suggested/asked. Cheers, Carlos 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 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) Resubmissions due to validation errors. I'm assuming (maybe incorrectly) that during (1) a new form instance will be instantiated, so a new model will be created with it that will return a model object from the repository. Then, during (2), form contents will be posted and bound to a fresh model object which was created from the deserialized LoadableDetachableModel. Under this assumptions I see no problem regarding reloads of the page in state (1) or in state (2). But maybe you mean that the model is instantiated when you create the page (not the form) so there will be just one moment satisfying (1) during the entire session. Sorry if this is all too obvious but take into account that I'm coming from a different controller/action mindset where the session is barely used. Cheers, Carlos On 3/29/07, Eelco Hillenius [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? 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 before his last non-submitted changes. 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -- Learn Wicket
Re: [Wicket-user] Binding and validating domain objects
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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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 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? A page is created when: - you do new MyPage() - someone requests a bookmarkable url (a link, the homepage, refresh of such a page) All subsequent requests will retrieve that page (and version) from the page store (can be the session, filesystem, database), and work on that instance. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Binding and validating domain objects
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list
