Re: validation and #updateModel

2010-07-21 Thread Ray Weidner
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

2010-07-21 Thread Ray Weidner
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





Re: validation and #updateModel

2010-07-20 Thread Jeremy Thomerson
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

2010-07-20 Thread Ray Weidner
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

2010-07-20 Thread Jeremy Thomerson
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

2010-07-20 Thread Igor Vaynberg
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

2010-07-20 Thread Jeremy Thomerson
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

2010-07-20 Thread Ray Weidner

 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

2010-07-20 Thread Jeremy Thomerson
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