On 2/27/06 7:28 AM, Michael Lackhoff wrote:
>> Try something like this instead:
>>
>> if(UNIVERSAL::isa($val, 'DateTime'))
>> {
>> $hash{$field} = $val->sprintf('%m.%d.%Y');
>> }
>
> Thanks, this looks better and it works if I change it to:
> $val->strftime('%d.%m.%Y');
Er, yeah, sorry about that :)
> If I see it right I had to replace all this well known stuff to the
> equivalents in Rose::HTML::Objects, without even knowing if there is
> an equivalent for everything. I don't think I want to go that far at
> the moment, especially since I don't think it a good idea to abondon
> template based HTML generation.
You'd still use the same templating system. You'd just pass the form object
to the template instead of passing a bunch of separate values. The gist of
it is:
$form = MyPersonForm->new; # $form "isa" Rose::HTML::Form
if(...form was submitted...)
{
$params = { ... }; # CGI-style name/value params hash ref
$form->params($params);
$form->init_form;
if($form->validate)
{
$person = $form->person_from_form; # Person object
do_something_with($person);
}
else # redisplay form
{
show_template(name => 'form.tt', args => { form => $form }
}
}
else # show empty form
{
show_template(name => 'form.tt', args => { form => $form }
}
# In foo.tt
[% IF form.error %}
<div class="error">[% form.error_html %]</div>
[% END %]
[% form.start_html %]
<b>Name:</b> [% form.field('name').html %]<br>
<b>Age:</b> [% form.field('age').html %]<br>
...
[% form.end_html %]
> But perhaps my first look at it was too superficial?
It's not an easy technique to grok if you haven't seen it before. There's a
separate list for this if you're interested:
http://lists.sourceforge.net/lists/listinfo/rose-html-objects
> I waited for the new release but I must admit I am still not totally
> convinced.
The big pay-off is when you have many, similar forms with complex fields.
You do the work to make your "library" of complex fields and common
sub-forms once, and then you re-use all those pieces. It's basically an
object-oriented "widget-based" approach to forms.
> Given the widespread use of CGI.pm I would find it of great help if I
> could stick to a CGI query object and don't have to use a
> Rose::HTML::Object.
They're two separate things. You'd use the CGI object to get the params
that you initialize the Rose::HTML::Form with. You can think of each field
object as a mutable version of the one-time, statically-generated HTML
strings produced by the various CGI.pm functions like textfield.
Of course, the big difference is that a Rose::HTML::Field object may
actually be made up of an arbitrary number of individual HTML fields. For
example, a date/time field made up of 3 text fields for month, day, and
year, plus 3 more text fields for hour, minute, and second, plus one pop-up
menu for am/pm.
>From the perspective of your code, that just looks like a single field with
a single value. That field object will do all of the parsing and so on for
you, giving you a convenient DateTime object back instead of individual
"pieces" of the value. This is why you can do:
$person = $form->person_form_form();
which, internally, will do the equivalent of:
$person = Person->new;
$person->some_date($form->field('some_date')->internal_value);
...repeat for each field...
return $person;
and you don't have to worry about what format the "some_date" value is in,
or whether it's actually seven values in the CGI params, etc. The some_date
field will return a DateTime object as its internal_value(), and the
some_date() Person method will accept such a value and properly format it
for whatever db you're connected to when you save() it.
And if you decide down the road to change your some_date field to be a
single text field instead, but with a JavaScript calendar pop-up widget or
something, you'd just swap the field object in your form object and not have
to change any other code as long as your new field also returned a DateTime
object as its internal value. This is how Rose::DB::Object and
Rose::HTML::Objects work together to isolate your code from changes in the
database and changes in the details of the forms and fields themselves, and
to isolate all your field validation, parsing, and formatting to individual,
pre-fab, reusable field objects.
> I know these should be methods of CGI.pm but I would appreciate
> something like object_from_form and init_with_object in RDBO with
> object = <CGI.pm query object>.
As you can see, it's a two-step process: init form object with CGI params,
then get an object from the form. That said, I do think a convenience
method named init_with_cgi() would be handy. I'll probably add it in the
next release.
-John
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
