My first thought was that those constraints should be generated into
the config files - just as I did in InstantCRUD, so that people can
modify them. But then actually it makes sense that the database
induced constraints are fixed. They are the minimal set of constraints
- so you only need to add other constraints to them not modify them.
There is another aspect of this - the list of fields a FormFu has, it
also can be deduced from the schema - and I think there is the place
for generation.
Is there any reason to split the ResoultSet name to schema and table?
Why not use
constraints_from_dbic: [ 'MyApp::Schema::Table' ]
?
--
Zbyszek
On 5/17/07, Carl Franks <[EMAIL PROTECTED]> wrote:
On 17/05/07, Carl Franks <[EMAIL PROTECTED]> wrote:
> At the moment, it adds constraints to fields which have the same name
> as an existing column.
> I plan on adding support for a 2nd argument, which would be a hashref
> mapping fields to columns (also in other related resultsets).
I've added basic support for fields in other tables, the syntax is...
$form->constraints_from_dbic(
[ 'MyApp::Schema', 'Person' ],
{
dongle => [ 'MyApp::Schema', 'Dongle' ],
}
);
Carl
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
_______________________________________________
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
