Re: validation and #updateModel
I haven't done that before, so I'll have to figure out how to do it. Thanks for the adviceI'll look into doing that, because I have seen this recommendation made to others, so I should probably learn. However, in the meantime, I think I may have a theory as to why this is happening. When the error was reproduced for me, it seems to happen only during certain errors uploading attachments using the MultiFileUploadField. Now that certain other issues were fixed with this control, I can only reproduce this problem by trying to upload a file larger than the maximum set in Form#setMaxSize. What you said earlier, about how only fields that failed validation should fail to be retained in the form, got me to thinking: since this restriction is set in the Form object, does that block the model update for ALL fields? That would make sense, but it would also make this method nearly unusable except on a dedicated form (i.e. a form used only for uploading files). In that case, I'm better off manually validating upload size. On Tue, Jul 20, 2010 at 5:13 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jul 20, 2010 at 1:22 PM, Ray Weidner ray.weidner.develo...@gmail.com wrote: Back to the original question, when you say all changes to the form are lost - do you mean that the form rerenders with absolutely no values filled out? Only the fields that failed conversion or validation should be blank. See, that throws me off, too. Yes, the supposedly valid fields are not being preserved after submit and fail validation. I would have thought that they should have been preserved, LDM be damned, but they aren't, so that was my theory as to what was causing this. So if that's not causing it, what could be causing such a thing? I'd including source code here, but I'm not even sure what part is causing the problem, so that would be a lot of code. Any ideas? Best thing to do is try to create a quickstart that reproduces it. Typically, you find your error while doing this. If not, you have something you can give us that we can quickly run to debug your problem. -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
Update: I was able to confirm my theory below. It was specifically MultiFileUploadField's validation of file size via Form#setMaxSize that was causing the problem. Again, I question the value of this method if this is the result. It sounds like you have to put attachment uploading in its own separate form. Is this supposed to be standard practice? On Wed, Jul 21, 2010 at 2:25 AM, Ray Weidner ray.weidner.develo...@gmail.com wrote: I haven't done that before, so I'll have to figure out how to do it. Thanks for the adviceI'll look into doing that, because I have seen this recommendation made to others, so I should probably learn. However, in the meantime, I think I may have a theory as to why this is happening. When the error was reproduced for me, it seems to happen only during certain errors uploading attachments using the MultiFileUploadField. Now that certain other issues were fixed with this control, I can only reproduce this problem by trying to upload a file larger than the maximum set in Form#setMaxSize. What you said earlier, about how only fields that failed validation should fail to be retained in the form, got me to thinking: since this restriction is set in the Form object, does that block the model update for ALL fields? That would make sense, but it would also make this method nearly unusable except on a dedicated form (i.e. a form used only for uploading files). In that case, I'm better off manually validating upload size. On Tue, Jul 20, 2010 at 5:13 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jul 20, 2010 at 1:22 PM, Ray Weidner ray.weidner.develo...@gmail.com wrote: Back to the original question, when you say all changes to the form are lost - do you mean that the form rerenders with absolutely no values filled out? Only the fields that failed conversion or validation should be blank. See, that throws me off, too. Yes, the supposedly valid fields are not being preserved after submit and fail validation. I would have thought that they should have been preserved, LDM be damned, but they aren't, so that was my theory as to what was causing this. So if that's not causing it, what could be causing such a thing? I'd including source code here, but I'm not even sure what part is causing the problem, so that would be a lot of code. Any ideas? Best thing to do is try to create a quickstart that reproduces it. Typically, you find your error while doing this. If not, you have something you can give us that we can quickly run to debug your problem. -- Jeremy Thomerson http://www.wickettraining.com
validation and #updateModel
Hi all, I have what I would think to be a fairly common usecase that I'd like to solve. I have a form with a model that is a LoadableDetachableModel wrapped in a CompoundPropertyModel. I wouldn't expect that to be unusual. However, when a form submit is failing validation for , all changes to the form are lost. I'm guessing that the LoadableDetachableModel, when combined with the blocked update to the model, is causing this. For the most part, I've been able to get around this by deferring most validation checks until #onSubmit, at which point I manually run through them and call #error on the appropriate components. Two problems: First, I can't defer all validation. Type conversions and the size of uploaded files are validated automatically, and you wouldn't want to have to rewrite that for yourself. Second, I don't want to defer all the validation. In so doing, I lose the benefits of Wicket handling all that stuff in the back end for me. I'm wondering if there's a possible work-around. What if, during the call to #onError, I was to call #updateModel? The javadoc gives a rather significant warning against using this method, but I'm wondering if it has some value here. The point is, if I force the model to be updated despite the validation failure, then changes will not be lost upon submission. Any thoughts?
Re: validation and #updateModel
On Tue, Jul 20, 2010 at 1:55 AM, Ray Weidner ray.weidner.develo...@gmail.com wrote: Hi all, I have what I would think to be a fairly common usecase that I'd like to solve. I have a form with a model that is a LoadableDetachableModel wrapped in a CompoundPropertyModel. I wouldn't expect that to be unusual. However, when a form submit is failing validation for , all changes to the form are lost. I'm guessing that the LoadableDetachableModel, when combined with the blocked update to the model, is causing this. For the most part, I've been able to get around this by deferring most validation checks until #onSubmit, at which point I manually run through them and call #error on the appropriate components. Two problems: First, I can't defer all validation. Type conversions and the size of uploaded files are validated automatically, and you wouldn't want to have to rewrite that for yourself. Second, I don't want to defer all the validation. In so doing, I lose the benefits of Wicket handling all that stuff in the back end for me. I'm wondering if there's a possible work-around. What if, during the call to #onError, I was to call #updateModel? The javadoc gives a rather significant warning against using this method, but I'm wondering if it has some value here. The point is, if I force the model to be updated despite the validation failure, then changes will not be lost upon submission. Any thoughts? Don't use a LoadableDetachableModel for a form. -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
That would certainly simplify things, but I find it indispensable when it comes to handling persistent entities, which you wouldn't want to serialize with the page. Taking a step back, how can a form map to persistent entities without resorting to LoadableDetachableModels? Not that I'm necessarily in a position to perform such a drastic refactoring at this stage in my project (I'm not). I'm just curious. But if anyone has an answer to my first problem, I'm still quite interested. Because I can't really replace LoadableDetachableModels at this stage of development. On Tue, Jul 20, 2010 at 2:59 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jul 20, 2010 at 1:55 AM, Ray Weidner ray.weidner.develo...@gmail.com wrote: Hi all, I have what I would think to be a fairly common usecase that I'd like to solve. I have a form with a model that is a LoadableDetachableModel wrapped in a CompoundPropertyModel. I wouldn't expect that to be unusual. However, when a form submit is failing validation for , all changes to the form are lost. I'm guessing that the LoadableDetachableModel, when combined with the blocked update to the model, is causing this. For the most part, I've been able to get around this by deferring most validation checks until #onSubmit, at which point I manually run through them and call #error on the appropriate components. Two problems: First, I can't defer all validation. Type conversions and the size of uploaded files are validated automatically, and you wouldn't want to have to rewrite that for yourself. Second, I don't want to defer all the validation. In so doing, I lose the benefits of Wicket handling all that stuff in the back end for me. I'm wondering if there's a possible work-around. What if, during the call to #onError, I was to call #updateModel? The javadoc gives a rather significant warning against using this method, but I'm wondering if it has some value here. The point is, if I force the model to be updated despite the validation failure, then changes will not be lost upon submission. Any thoughts? Don't use a LoadableDetachableModel for a form. -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
On Tue, Jul 20, 2010 at 2:19 AM, Ray Weidner ray.weidner.develo...@gmail.com wrote: That would certainly simplify things, but I find it indispensable when it comes to handling persistent entities, which you wouldn't want to serialize with the page. Taking a step back, how can a form map to persistent entities without resorting to LoadableDetachableModels? Not that I'm necessarily in a position to perform such a drastic refactoring at this stage in my project (I'm not). I'm just curious. But if anyone has an answer to my first problem, I'm still quite interested. Because I can't really replace LoadableDetachableModels at this stage of development. Typically, I use LDM's for every place that I am viewing data, and a regular serializable model for places that I'm editing data. You must be able to persist changes across requests (without persisting to the long-term storage), which means that you'll need to be able to serialize things. Back to the original question, when you say all changes to the form are lost - do you mean that the form rerenders with absolutely no values filled out? Only the fields that failed conversion or validation should be blank. Others should have their data still in them in an unconverted form even though the converted / validated form has not been pushed to the model yet. If all the fields are truly blank, is it possible that you're somehow reinitializing those fields? Perhaps redirecting on error to a new instance of the page? -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
On Tue, Jul 20, 2010 at 12:53 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Typically, I use LDM's for every place that I am viewing data, and a regular serializable model for places that I'm editing data. You must be able to persist changes across requests (without persisting to the long-term storage), which means that you'll need to be able to serialize things. this is not true :) the formcomponents themselves preserve the state so using an LDM for a form is feasible. the sequence is basically * load entity - model * call setters - form component models * flush/close session - somewhere -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: validation and #updateModel
On Tue, Jul 20, 2010 at 10:20 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Tue, Jul 20, 2010 at 12:53 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Typically, I use LDM's for every place that I am viewing data, and a regular serializable model for places that I'm editing data. You must be able to persist changes across requests (without persisting to the long-term storage), which means that you'll need to be able to serialize things. this is not true :) the formcomponents themselves preserve the state so using an LDM for a form is feasible. the sequence is basically * load entity - model * call setters - form component models * flush/close session - somewhere Right, which is why I said in the second paragraph: Only the fields that failed conversion or validation should be blank. Others should have their data still in them in an unconverted form even though the converted / validated form has not been pushed to the model yet In the first paragraph I should have been more clear - I use serializable models for where I'm editing data and passing it to other pages (i.e. multi-step wizards). But, in this case, he seems to be in a single form, so the components should still have state unless he's reinitializing them somehow (redirecting to new page, etc). -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
Back to the original question, when you say all changes to the form are lost - do you mean that the form rerenders with absolutely no values filled out? Only the fields that failed conversion or validation should be blank. See, that throws me off, too. Yes, the supposedly valid fields are not being preserved after submit and fail validation. I would have thought that they should have been preserved, LDM be damned, but they aren't, so that was my theory as to what was causing this. So if that's not causing it, what could be causing such a thing? I'd including source code here, but I'm not even sure what part is causing the problem, so that would be a lot of code. Any ideas? On Tue, Jul 20, 2010 at 11:55 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jul 20, 2010 at 10:20 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Tue, Jul 20, 2010 at 12:53 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Typically, I use LDM's for every place that I am viewing data, and a regular serializable model for places that I'm editing data. You must be able to persist changes across requests (without persisting to the long-term storage), which means that you'll need to be able to serialize things. this is not true :) the formcomponents themselves preserve the state so using an LDM for a form is feasible. the sequence is basically * load entity - model * call setters - form component models * flush/close session - somewhere Right, which is why I said in the second paragraph: Only the fields that failed conversion or validation should be blank. Others should have their data still in them in an unconverted form even though the converted / validated form has not been pushed to the model yet In the first paragraph I should have been more clear - I use serializable models for where I'm editing data and passing it to other pages (i.e. multi-step wizards). But, in this case, he seems to be in a single form, so the components should still have state unless he's reinitializing them somehow (redirecting to new page, etc). -- Jeremy Thomerson http://www.wickettraining.com
Re: validation and #updateModel
On Tue, Jul 20, 2010 at 1:22 PM, Ray Weidner ray.weidner.develo...@gmail.com wrote: Back to the original question, when you say all changes to the form are lost - do you mean that the form rerenders with absolutely no values filled out? Only the fields that failed conversion or validation should be blank. See, that throws me off, too. Yes, the supposedly valid fields are not being preserved after submit and fail validation. I would have thought that they should have been preserved, LDM be damned, but they aren't, so that was my theory as to what was causing this. So if that's not causing it, what could be causing such a thing? I'd including source code here, but I'm not even sure what part is causing the problem, so that would be a lot of code. Any ideas? Best thing to do is try to create a quickstart that reproduces it. Typically, you find your error while doing this. If not, you have something you can give us that we can quickly run to debug your problem. -- Jeremy Thomerson http://www.wickettraining.com
