>
> That is, I create a controller plus templates that given any model
> class/object, will introspect it (or will get the columns and their
> corresponding types from an appropriate description/annotation) and
> create a form for each of C,R,U,D (actually one with different actions
> available)
I use formalchemy for that.
> In the case of relations I tend to allow many-to-one relations to be
> edited in the many end (i.e. the model class where the foreign key is
> stored).
I see. But this doesn't suit well in many cases. A common task is to
attach many (non-existing yet) objects to one-end object. Many-end
objects are created in process of editing. What could be the pattern?
> Given A(id, fk_b_id), B(id), with A.b holding a reference to a B
> object via the A.fk_b_id foreign key ('many' end of relationship), and
> B.list_of_a holding a list of references to objects of A (the 'one'
> end of relationship), I tend to put a combobox in the form for A,
> allowing it to select one of the available B objects. I also tend not
> to put some kind of multiple select list in the form for editing B
> since many of my users may not know how to select multiple entries in
> such a control (by holding Ctrl down).
Multiselect is evil here. Non-informative and is total foobar when the
number of items is sufficiently big. One click by mistake and all your
selection blown. Plus, no edit capabilities. Imagine a list of
attached images, which you want to CRUD.
Natural widget here is the sub-grid, IMHO. With formalchemy it is
_already_ known (by introspection, or via manual configuration) how to
display unconstrained (by the relation key) list of objects of type X.
Similarly it is known how to display edit form for objects of type X.
The problem is how to constrain by relation key the list of
subordinate objects Y, put that list verbatim to X edit/new form, and
allow this constraint to propagate to edit/new forms for Y objects. If
it were done, (in theory, I admit) a developer could relay the most of
configuration to formalchemy engine, thus generalizing the interface.
--
Vladimir
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
