I've been using Catalyst::Model::FormFu for this purpose.
I wanted to keep as much as possible in the editable .yml files so my
html coders can access it easily, so I wanted to keep this type of stuff
away from .yml files.
What I ended up doing was to create a Catalyst model that filters the
config file for dynamic content, and does a replace
For example, my .yml file looks like this:
- type: select
options: __dynamic(foo)__
then, Data::Visitor is used to traverse the config file. When it
encounters a construct like __dynamic(xxx)__, it calls the appropriate
method in the model:
sub foo {
return [
... generate a construct suitable for formfu ...
]
}
The result of calling this method replaces the original __dynamic(foo)__
With built-in caching, this approach has been working very nicely for me.
--d
Brian Cassidy wrote:
Hey All,
A common theme we're running into is providing select boxes, and
(radio|checkbox) groups with data stored in the database.
Select boxes seem to be pretty easy
package MyApp::Form::Element::Thingy;
use base qw( HTML::FormFu::Element::select );
sub new {
my $self = shift->SUPER::new( @_ );
my $c = $self->form->stash->{ context };
my $thingies
= $c->model( 'DB::Thingy' )->search( { foo => bar } );
$self->options(
[ {},
map {
{ label => $_->name, value => $_->id }
} $thingies->all
]
);
return $self;
}
1;
Is this good idea? Is there a recommended way?
Creating a group of checkboxes and/or radio buttons from a db table
seems to be a much harder problem -- is there a recommended solution for
that as well?
-Brian
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
