Hi, Mark! Thanks for feedback.
> I think too often we look at how to best do our job by using a tool to > get our database into the form of an html form. If you take the time > to learn the tools, then this can work for you. The problem is that > often we're so mired in getting this kind of stuff to work > automagically that we forget that the end result is to make software > for the end user, not for the database. Right! I am the user and I speak for formalchemy. > > Stuff like using a datagrid (controlling a 1-M from the one side) or a > drop-down / select box (controlling a 1-M from the many side) are just > two possible ways that this can be dealt with, and there's no way you > can look at a 1-M relationship in the database and figure out what's > best. Reasonably small record count, reasonable small fields count -- these could be the criteria of *boxes. But presenting hundreds of unmanageable (no filtering, no sorting, no nothing) records in *boxes is unlikely a good practice. > You can guess, but that's all you're doing: guessing. You really > find out by talking to the user of your application. I *am* the user. And am trying to reflect what would it be the most comfortable to me to deal with. > Sometimes an > entity and it's children can be so large that a data grid would be > unwieldy for the children, but it still makes sense to add modify > children from the parent's page. Here I would put the children in it's > own page/form, which is reachable from a link or button on the > parent's admin page. I'm inclined to do so, but still as the user I want related stuff be visible on parent view. May be partially, but visible. > > The advantage to this approach is that the individual forms are > typically just one entity, and thus simpler. Right. One entity -- one form, and one grid (list). But take that 1-M relation is a _field_, not entity. Ans as a field it should have renderers: read-only to display in grids, read-write to display on forms. I'm asking for an advice, whether read-only 1-M field renderer should trivially be the filtered (by relation key) grid for M-end entity. > The disadvantage is that > the user might take more clicks to get to what you they want to edit. I can live with that, but if we take that related stuff should be visible on parent view, the synchronization problem arises. And the solutions to it tend to be ugly (reload of the parent page, often, which hits usability). > But in the end, you can't have one "pattern" to do it all. Just > because you've found/made a great hammer doesn't mean you should be > hammering in screws. > Right. But deduction (in sense of customizing a good guess) is the primary technique of my development paradigm. Formalchemy does much of guessing, the missing part is guessing on displaying 1-M relations. > Now, if you're talking about a specific situation, such as "Creating a > form for the parent along with a datagrid for all the children all on > one page", then we can talk implementation. Exactly. Suppose I want to CRUD images related to an object. The situation is hardened here since images (along with other uploaded stuff), as indirectly accessed objects, should in addition be provided with interface to upload them. How would you do that? TIA, -- 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.
