This project is read-only.

Content types with parent-child relationships and grid edit views

Topics: General
Feb 17, 2013 at 12:04 PM
Just wondering if there is or has been any thought put into providing a simple approach to implementing content types with parent child relationships and grid editing of child items within the parent view in Orchard?

Consider a common case where you need a content type that represents an order form (a content type) that might have a number of general fields like name, description, active, etc. This form might then have a number of products.

At present we could define a content type for the order form, and make it a container, then define a content type for products and make them containable.

It would be great if there was a standard way that we could display a grid (e.g. using something like the open source grid at within the edit view for the parent item.

In this example, I would then be able to edit products quickly, in-line in a grid in the edit view of the order form.

Some features that would be nice...
  1. Ability to indicate which fields of the child content type are displayed as columns in the grid when editing the parent content item.
  2. Ability to indicate which fields of the child content type are editable/readonly in the grid
  3. Ability to select a row in the grid and click edit to bring up the edit view for the child content item.
Might this be a feature that the existing Container part could be extended to include? Maybe an option "Display contained items in edit view within grid" or something like that? Then the Containable part could be extended to provide "Display in Grid & Editable in Grid" options for each field on the content type that the containable part is associated with.

Just thoughts...any comments?
Feb 17, 2013 at 10:22 PM
The Common part has a Container property that is used, among other places, in the blog/post relationship. You can use the Container and Containable parts on your own types to the same effect (they use the same Container property from the Common part). The List module (now deprecated) was implementing pretty much what you describe, but it was confusing people who thought it would enable them to put a given item under several containers. In other words, they were confusing parent-child with taxonomy. We retired the module because the confusion was almost universal, and we started to tell people to use the Taxonomies module instead, because that's what they wanted most of the time. We also later introduced the Content Picker Field that enables you to implement simple relationships between content items, without any code. When you use a content picker field configured for multiple items, you get a grid UI to manage the related items, with drag and drop to reorder them.
Feb 17, 2013 at 10:53 PM
It seems there's no relation between the Content Picker field and the Container/Containable parts?

I've defined a content type that has the containable part (eg. ChildItemType). I've defined a content type that is a container (eg. ParentItemType) and have added a content picker field and also added the Container part and selected "ChildItemType" for the Contains property of the content item.

Some notes...
  1. At present when you add the container part to a content type, you can then select the child content type when creating a parent content item (ie. an instance of the parent content type). It would be good if you could limit what the child content type is in the configuration of the Container part of the parent content type (thus enforcing that all content items of the parent content type must always contain children of the specified type)
  2. It would be good if the content picker field was able to restrict the content items available in the picker to only those of the content type that I have selected in the "Contains" field of the Container part.
  3. Could we extend the content picker to allow you to create instances of new child items as well as select existing? Kind of like the media picker, where you can pick from the existing library or upload a new item.
  4. It would be great to allow the grid to be editable inline. Could the containable part be extended to offer additional properties for each field of the child content type - like "Editable Inline" and "Display Inline"? The content picker field could then take these into account when generating the grid of child content items.
I guess I'm thinking a good place to be would be where a content maintainer could easily add new child rows and edit existing rows inline from the parent content item.

These are changes I'd be willing to have a crack at implementing, but I'd like to be sure I take an approach where it could be pulled back into the core product at some point in the future.
Feb 17, 2013 at 11:55 PM
No, there is no relation between content picker field and container/containable. A good thing as that enables you to have more than one field per type.
  1. I'm pretty sure the container part already lets you configure what type it accepts.
  2. That's implemented in 1.x
  3. Sure. That could be done.
  4. That's not going to happen, I think. The list of items in content picker field is only displaying the item in summary form.
If you want to take the existing lists module and run with it, you can of course do that, it's open source. As for taking that into core, well, #1 and #2 are done if I'm not mistaken, so maybe #3 but #4 should be a custom module if you decide to build it.
Feb 18, 2013 at 12:05 AM
  1. The container part does let you configure what type is exists, but this configuration is exposed when creating a content item, rather than via the Container configuration of the content type. This means you need to rely on the content maintainer selecting the right child content type each time the create an instance of the parent content type.
  2. I'm not seeing this behaviour. I have a content type with both the "Container" part and the "Content Picker" field, and when I edit a parent content item, if I press the "Add" button to bring up the content picker, it displays all content items regardless of content type. As you say, this doesn't really need to have anything to do with the Container part. We'd just need an extra configuration option on the Content Picker field to allow you to restrict it to content items of a specific content type.
I'll add 3 and 4 to my todo list :o)
Feb 19, 2013 at 5:57 AM
I checked 2 on the latest in the 1.x branch and I was able to configure the field so that it would take only items of type Page. It works.
Feb 19, 2013 at 6:16 AM
hmm. Maybe this is something that's not in the 1.6 release?

I only get 2 checkboxes (require item & allow multiple) in the field configuration for the content picker.
Feb 19, 2013 at 6:19 AM
hmmm, yes, as I said, it's in the 1.x branch ;) The 1.x branch is where the current development is done. It's, by definition, not in the latest release...
Feb 19, 2013 at 6:30 AM
ah ha...I see now :o) is the "default" branch the source as at the last release? ....because up until now I've been forking off the "default" branch and submitting pull-requests for for issues from there.
Feb 19, 2013 at 8:16 AM
Yes, default is the latest released.