[Grok-dev] How to use auto-forms to quickly handle nested objects

[Steve Schmechel]

Hi Tim,

I did see your tutorial and I will be using some of the techniques you explained.

However, location and mammoth, while represented by different model objects, have a one-to-one relationship.  

I'm thinking of something more like a location history.  A one-to-many relationship.  Where, for a particular mammoth, you have notes about when and where location changes occurred.

While being able to see a summary of the history within the mammoth page would be nice, at this point I just want a way to work with the model objects in a browser interface.

Also, imagine that a mammoth had "location history", "feedings", "wool sheering history", etc.  Adapting all of these objects into one view might become cumbersome.

Maybe, I am thinking too relationally.  I am rather new to Zope3 and Grok.

This was the same problem I had with trying to use Plone for an application where a hierarchical arrangement of content pieces exists:

- Folders can contain various types of content or other folders.
- A content object can not directly contain other content objects or a folder.
- Folders don't provide content fields.  (At best a folder URL can appear like one by substituting a default content object.)

You end up putting all the sub-content of a given type in a separate folder and then each object needs to query to find it's related objects based on a keyword or something.

Managing related content in different spots results in additional complexity.  Whenever you move or delete something, you have to query around and figure out what might be affected.

That is why I am hoping for simple "containment" of the hierarchy as a starting point.  That way deleting a mammoth will delete all the "feedings" and other information that goes with it.  This is easy to do in Python code.  I am just hoping there is a simple case for making the auto-forms follow such an arrangement.

Maybe there is some revelation that I have not experienced yet and I am handling this in completely the wrong way.  

If there is a better way to handle hierarchical relationships, please enlighten me.  

If I just need to face the fact that this will be tough and I am going to need to learn a lot about adapters and write a bunch of code to make this happen, then tell me the hard truth.
 
Thanks in advance,
Steve


> Hi Steve,
> 
> In case you missed it, I think this may help
> http://grok.zope.org/documentation/tutorial/work-with-forms/using-multiple-schemas-with-a-form
> 
> It is an approach I'll be trying over the next few days
> with a probelm
> that is similar to yours.
> 
> HTH,
> Tim
> 
> 
> On Sat, 2009-03-21 at 21:19 -0700, Steve Schmechel wrote:
> > If you have a "grok.Model based" object that
> contains one or more collections of other "grok.Model
> based" objects, is there are way to quickly represent
> this hierarchy using auto-forms?
> > 
> > I cannot find any examples of this nested structure in
> tutorials, how-to's, or example applications.  This
> would seem to be a natural layout for many object domains.  
> > 
> > Is this generally handled differently?  Is everything
> handled as "annotations"?  Is everything jammed in
> the main application "grok.Container" and then
> located as needed using separate indexes/catalogs?
> > 
> > Take, for example, the mammoth example in:
> >
> http://grok.zope.org/documentation/tutorial/work-with-forms
> > 
> > Mammoth(grok.Model) objects are stored in the
> MammothApplication(grok.Application, grok.Container) and
> auto-forms are used to view, add and edit mammoths.
> > 
> > If a caveman wanted to track how much food his mammoth
> was consuming, we might have a collection of
> "feedings" for a given mammoth.  Each
> "feeding" object would have attributes/fields for
> the "type of food" and the "weight". 
> For simplicity, both attributes could be just user-entered
> text but the feeding should be derived from grok.Model (not
> a list of string pairs or something like that).
> > 
> > It appears that zope.schema has a
> "Container" type and a "Dict" type.  
> > (grok.Container would map to Dict???)
> > Assuming we just want to be able to record the
> feedings and be able to view a simple listing of feedings
> for a given mammoth, what would be the quickest way to do
> this? 
> > 
> > Can the auto-forms generate an "add" button
> on the Mammoth auto-form that takes you to a
> "grok.AddForm" for a Feeding?  Can the auto-form
> simply generate a hyper-link when displaying the
> "Feedings" field (grok.Container), so that you can
> navigate to that object and render a view/template that
> lists the individual feedings?
> > 
> > I know all of this is rather basic and wouldn't
> make for a great user interface, but it would allow you to
> quickly prototype your content objects.
> > 
> > I believe the whole "custom widgets" and
> "multi-adapters" route is probably the right way
> to do this sort of thing.  But it is a lot for a newbie to
> get their head around and I haven't seen any simple
> examples applied in any tutorials.
> > 
> > Any advice is appreciated.  I will include what I
> learn in a tutorial that I am writing.  I really just need
> to be steered in the right direction.
> > 
> > Thanks,
> > Steve
> > 
> > 
> >       
> > _______________________________________________
> > Grok-dev mailing list
> > Grok-dev at zope.org
> > http://mail.zope.org/mailman/listinfo/grok-dev
> -- 
> Timothy Cook, MSc
> Health Informatics Research & Development Services
> LinkedIn
> Profile:http://www.linkedin.com/in/timothywaynecook 
> Skype ID == timothy.cook 
> **************************************************************
> *You may get my Public GPG key from  popular keyservers or 
>  *
> *from this link
> http://timothywayne.cook.googlepages.com/home*
> **************************************************************