[DAVEBAIRD - Tue Jul 19 19:46:03 2005]:
Show quoted text> [guest - Tue Jul 19 14:32:19 2005]:
>
> > There's a significant difference in the list / editlist modes as
> > currently implemented in Maypole::FB. The Mason templates assume
> > the columns to be rendered are model_class->display_columns. List
> > mode calls Maypole::Plugin::QuickTable->tabulate, which also checks
> > display_columns to determine what columns to return. However,
> > editlist mode calls the FormBuilder methods, the result being that
> > it shows the fields passed in the FB args.
> >
> > This causes a dilemma for a simple setup I have, where five fields are
> > in display_columns: one primary key, two editable, and two auto-
> > generated (but useful to be able to see!). I've set the FB fields
> > to the two editable fields. This is the correct behavior for the
> > addnew template, where only those two fields are relevant for
> > creating a new row, but suboptimal for search, where it should be
> > possible to search any field. However, the real issue comes up in
> > the editlist mode, where I get a table with five columns in the
> > header, but only two in the actual rows (plus action buttons)!
>
> Yes, tabulate() blindly gives you back display_columns(), there's no way
> to ask it for a different set of columns in the way you can ask FB. And
> anyway, as_form now also gives you fields for has_many and might_have
> relationships, which tabulate doesn't figure out.
>
> I've added a 'fields' argument to tabulate. If not present, the field
> list defaults to display_columns plus has_many accessors. Should be easy
> enough to add might_have accessors, but I need to keep the ordering of
> fields in sync between as_form and tabulate.
>
> As part of this, I've also added a maybe_many_link_views method to
> MP::Plugin::QuickTable, and removed the view_related template. So in the
> listview, and in the view template, has_many items are represented as a
> list inside a table cell. In editlistview, they are represented as a
> scrollable menu widget.
>
>
> >
> > What I would like to have happen is that the only _editable_ columns
> > are those two, but that the other columns still show up. This
> > strikes me as a reasonable general solution for this kind of case.
> > I can see various ways of doing it by tweaking templates and so on,
> > but it would be nice if Maypole::FB offered somewhat more
> > abstraction above the "raw" FormBuilder level. Different subsets of
> > columns are relevant for different purposes. This would also make
> > template coding much less tedious. I'm not completely sure what the
> > best way to do it would be, will have to think about it more, but
> > it seemed a good idea to post this here and make those aware of it
> > who might care.
>
>
> I'm not clear what these 'autogenerated' fields are - are they has_many
> relationships?
>
> More abstraction - I'm certainly open to suggestions.
> Alternatively/additionally, suggestions for more intelligent use of
> metadata would be useful too.
>
> However, if these customisations are specific to a given class, then
> they can all be implemented in class-specific templates, overriding the
> factory templates, simply by passing explicit column lists to the
> as_form calls.
>
> I'm not fully understanding what this use case is though. Maybe with the
> added consistency between the list modes, it'll become clearer.
>
> I'll write up the changes files and get new versions of QuickTable,
> MP::FB and CDBI::FB released.
>
> d.
>
> d.
There's now much more fine-grained control over which lists of fields
get used where (see all the *_columns and *_fields methods in
MP::FB::Model), and the templates and form generation use the same lists
in the same modes.
d.
