At 08:25 PM 6/8/2001 +0200, Gerald Richter wrote:
> > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > > HTML::Embperl
> > >
> > >For me, this has one major win over the other toolkits: auto form
> > >population from a hash. The online mortgage application system I
> > >wrote has about 1,800 form fields, which have to be populated with
> > >data from a database. By making the form fields match DB column
> > >names, I can reduce the code to do this to:
> > >
> > > my $data = $dbh->fetchrow_hashref($query);
> > > %fdat = (%fdat, %$data);
> > >
> > >Embperl then parses the form and populates it with the matching
> > >name=>value pairs in %fdat, including select options. Beautiful!
> >
> > Not that it's a reality now, but this is one of the things that the Perl
> > Widget Library project on source forge is hoping to accomplish for
>template
> > languages. It's a cross template way of organizing form information and
>map
> > it to db fields.
> >
> > The reality is that there are many fields that cannot map easily 1-1 to a
> > database as you say. eg a date in a database is usually a date field. But
> > in a form, it might be a combination of 3 form fields (dropdown for month,
> > year and day separately).
> >
>
>Such things could be solved by using DBIx::Recordset for database access and
>define some filters, which are able to transform the content of a field
>to/from format you need it.
Well, that assumes everything is a database... "everything I think I see,
looks like a database to me..."
If you look at PHP's GPC model and then realize that it goes farther into
allowing other datasources such as S or a DB or a secondary DB if the first
one is empty for that field, then you'll see that abstracting it in a
common way rather than a DBI-specific view is much more powerful and is
something that applications do occasionally have to do.
Writing a filter is doable but really kind of a hack really.
