[html-formfu] Re: Model::DBIC - dealing with SELECT boxes from lookup tables

[Zbigniew Lukasiak]

On Jan 29, 2008 3:12 PM, Carl Franks <fireartist at gmail.com> wrote:
> I've copied multiple messages into a single reply, to keep things together...
>
> On 26/01/2008, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> >
> > I've just committed a patch for Model::DBIC with tests for dealing
> > with SELECT boxes loaded from lookup tables (for belongs_to
> > relationship).  It needs to have the schema on the stash - if you just
> > put the Catalyst context there it will not work.  I think we agreed
> > that schema on stash is better - because it does not tie the Model to
> > Catalyst.  I am also volunteering to change the
> > Catalyst::Controller::FormFu to put the schema on the stash - and then
> > we could delete the old code dealing with Context.
>
> The context was being put onto the stash long before Model/DBIC
> existed, and has other uses.
> I know for example that brian c. has a custom element that uses the context.
>
> I refactored the resultset code out of options_from_model() into a
> separate routine, and made it able to handle getting the resultset
> from both
>     stash->{schema} and
>     stash->{context}
>
> I don't think it's necessary to break code already setting {model} and
> expecting it to get it from the {context}.
> This means, if your schema is on the stash, your element can do:
>     db: { resultset: Book }
>
> or, if just the context is on the stash, you can still do:
>     db: { model: 'Schema::Book' }
>
> On 27/01/2008, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> > Now when I think about it - maybe it is good time to refactor the
> > model stuff.  Maybe something like this in the config:
> > model:
> >   class: DBIC
> >   name: DBSchema            (if not defined than the default would be
> > used - $c->model() )
>
> Does this refer to the Cat-Controller config, form config, or element config?
>
> I've updated Catalyst-Controller-HTML-FormFu to support a
> 'model_stash' config option.
> This accepts a hashref, with each key referring to the form stash key,
> and the value referring to the Catalyst model.
> e.g.
>     model_stash: { schema: 'MySchema' }
> is equivalent to:
>     $form->stash->{schema} = $c->model('MySchema');
>
> btw, options_from_model() currently has
>     stash->{context} and
>     stash->{schema}
> hardcoded - these will need to be made configurable - as they can be
> configured with the Cat-controller.
> e.g.
>     context_stash: 'c'
> lets you puts the controller on stash->{c} instead.
> And obviously, the way I've implemented 'model_stash', means it's not
> necessarily on stash->{schema}
> (and we want to allow people to be able to use multiple schemas at once.
>
> Probably
>     db:
>       schema: 'foo_schema'
>       resultset: 'Book'
>
> or, for context:
>     db:
>       context: 'c'
>       model: 'FooSchema::Book'
>

For the start: $c->model( 'FooSchema::Book' ) is a DBIx::Class::ResultSet
but $c->model( 'FooSchema' ) is a DBIx::Class::Schema.

And $c->model() will most probably be a schema as well (if the first
model is a DBIC model).

Those two things are different and that's why I proposed to use two
parameters 'schema' and 'resultset' instead of that one 'model'.  This
is needed when you pull the values for two SELECT fields from
different (lookup) tables.

Since the schema is the representation of the whole database I was not
thinking that anyone would need to use different schemas per field.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/