Trouble with object_from_form

[jfrm]

I've just upgraded to PERL 5.16.3 and Rose::HTML::Objects 0.618 and Rose::DB 0.770 and Rose::DB::Object 0.805 to ensure currency but this problem still exists.  No doubt, it's something I'm doing wrong but I spent 2 hours this a.m. trying to work it out and am completely stumped so any help would be gratefully received.  To summarise I have a form that does not update all specified fields and when object_from_form is run, it seems to be resetting any fields that are not on the form.  I am using the following advice given previously in this forum:

#If you know for sure you're doing an update, you can always call $object->update.  But it's common that a form does not include

#every field in a table, so a safer bet is to first load() the object based on the primary key value in the form (if any) and then pass that

#loaded object to *_from_form().  That way any existing fields are preserved and any new values from the form are merged with them. 

my $prodobj = MG::Product->new(prodcode => $prodcode)->load; 

my $form = PROD::ProductForm->new;

$form->init_fields_with_cgi($cgi, $prodobj);   

print "!!! ".$form->field('Description')->internal_value."<br>";

if ($form->validate) {

print "1: ".$prodobj->Description;

my $updatedobject = $form->product_from_form($prodobj);  # this just doesnt' work - resets the fields e.g. Description

print "2: ".$updatedobject->Description;

                }

[Fri Apr 26 14:21:01 2013] opproduct.pl: Use of uninitialized value in concatenation (.) or string at C:/Information/mgroot/cgi-bin/opproduct.pl line 564.
[Fri Apr 26 14:21:01 2013] opproduct.pl:  at C:/Information/mgroot/cgi-bin/opproduct.pl line 564.

The print lines are for debugging and produce:

!!! 
1^^^Giant Snakes and Ladders
2^^^0

Any suggestions as to how can I dig in and investigate this further?

[John Siracusa]

I can't tell without seeing the rest of the code. Try making a
runnable, self-contained example script that reproduces the problem.

-John

[jfrm]

It was too hard for me to do that.  However, I have managed to work around it. I am going to try to explain in case it is useful for anyone else.  

What I have discovered (and this may be obvious for some) is that each form has  fields defined in the module and whether or not you use all the fields or not, Rose assumes that they are used.  So if you define a form and then only display and allow some of its fields to be set, the form fields that you haven't used still exist and when you come to save the form, they are reset.  This is what caused my problem.  The workaround was to create a second module consisting only of the fields that I wished to use on this particular page (even though some of those fields are also used in another form module elsewhere).  As all the fields are used and displayed, any fields in the database record that are not defined in the form module were just ignored and not reset.

I am interested to know if this is the right way to go about it or if there is a better way.  For instance, a real-life requirement might be to have a form corresponding to a database record with a field 'imperialormetric'.  If this field is set to 'metric', you want to set another field (in the form and database) called 'cm'.  If it's set to 'imperial', you want to set another field called 'inches'.  So in the form that is displayed to the user, when they select 'metric', you might want to only display the field 'cm' and when they select imperial, you would only want to display the field 'inches'.  If you do this, then when 'metric' is selected, because the 'inches' field isn't displayed, upon submitting the form, any value in the inches field is lost.  

One way to get around this is to display both 'inches' and 'cm' fields regardless - it doesn't hurt but isn't slick.  Another way to get around it would be to have 2 completely separate form modules - with the same fields except one would not have the 'inches' field and the other would not have the 'cm' field.  And then you would use a different module depending upon how 'imperialormetric' is set.

Anyway, I expect I don't fully understand what's happening behind the scenes but this is just my perspective for anyone scratching their head over the same issue in the future.

[John Siracusa]

On Wed, May 1, 2013 at 1:05 PM, jfrm <ja...@mastersgames.com> wrote:
> I am interested to know if this is the right way to go about it or if there
> is a better way.

Writing your own object_from_form()-type method that behaves the way
you want it to might be simpler than making multiple form classes with
different combinations of fields. The bundled object_from_form()
method is really just a convenience/helper method and an example of
something you might write. You don't have to use it if you don't want
to.

-John