On Feb 12, 2008, at 10:57 AM, Carl Franks wrote:
On 11/02/2008, Andreas Marienborg <[EMAIL PROTECTED]> wrote:
Hello :)
I know got my options_from_model working nicely, just two small
questions:
1: line 36 checks data_type against a regexp without checking for
definedness/truthness, which results in alot of warnings for schema/
sources that do this:
__PACKAGE__->add_columns(qw/id title blabla/);
Ok, that should now be fixed with revision 868
sweetness :)
second question:
I need to constraint my options in a select based on the user that is
logged in. Is that possible, or should I start tailing trunk and try
to cook up a patch that lets you specify a token or somesuch replaced
by $c->user->id for instance?
I've already added support in trunk for adding a DBIC constraint based
on a value on the form stash.
So, in your element config:
---
type: Select
model_config:
DBIC:
condition_from_stash:
$column-name: $stash-key
Will essentially do:
$row->search({ column-name => $form->stash->{ $stash-key } });
So if you can get the user id onto the stash easily enough, this might
be a solution.
I presume I can do this in my controllers and it will be work when I
render the form in my controller afterwards?
Otherwise, I think it would probably be best to implement this as a
custom element - a subclass of Select.
I'm not really wanting any core functionality to rely on Catalyst.
So, this would probably require abstracting the options_from_model() a
bit, to allow a hook for your subclass to add its DBIC constraint.
Feel free to create a new folder in trunk/ to experiment with this. It
would make sense to have any Catalyst-specific functionality either in
a new package HTML-FormFu-Catalyst or in the
Catalyst-Controller-HTML-FormFu dist.
I'll see if the other stuff works, and if there will be any need for
it after that.
...open to other suggestions though.
It's very hard to provide an automatic way to support this kind of
stuff, purely from a config file.
Either you end up with a million methods, for every option that
someone comes up with, or you end up trying to make a turing-complete
programming language in YAML :P
I vote for the last option :p TCYAML :p
I might also be wanting to start some HTML::FormFu::LDAP along the
lines of HTML::FormFu::DBIC with constraints etc, as we might need
that for a job project
- andreas
_______________________________________________
HTML-FormFu mailing list
[email protected]
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
