I've just released my GridFieldRelationHandler components at as module that you can get from here. This module provides two components, one for a has_one and one for a has_many or many_many, that emulates the radio buttons/checkboxes from the HasOneCTF, HasManyCTF and ManyManyCTF from SilverStripe 2.4 in GridField. See the attached screen shot for an example with a has_many relationship.

Before SilverStripe 3.0.3 or the current 3.0 branch on github, this does need a patch to framework/forms/gridfield/GridFieldPaginator.php to get the has_many/many_many component working properly with pagination. That patch is available here.

For more information, consult the readme.

Wow. Ambitious project! Nice work.

The thing I never liked about RelationDOM or its CTF counterpart was that it creates a really bizarre user experience. The use of a checkbox as a means to include a record is not a convention that many users are familiar with. If bulk editing/deleting is ever offered for GridField, it's going to create a checkbox catastrophe.

Do you think there's something better than a checkbox that we can use to show the user that these records appear on the page? Something that isn't compromised by pagination?

What about dragging a record into a drop area? That way, you can see what records are included no matter where you are in the grid, and it's a more familiar metaphor for showing one thing goes to another.

---------------
Silverstripe tips, tutorials, screencasts, and more. http://www.leftandmain.com

Without changing the many component to behave like the HasOne one (where you pass in the relation to the component), the paginator will always get in the way. At the moment, it takes the current list, undoes the relation filter and changes the many_many join from a left join to an inner join. Needs to go before the paginator so that the number of pages is correct. (The patch needed before 3.0.3 gets the paginator to use the modified list, rather than the one passed to the GridField to start with).

Personally, I think that the default GridField_RelationHandler (and, correspondingly, the standard CTF) are a much better way of displaying relations, and they both provide a nice way of adding new items to the relation. The problem is always going to be an efficient way of adding existing items to the relation (the GridFieldAddExistingAutocompleter is far from efficient). I do have some ideas on how to make the interface more intuitive (a toggle that switches between just the relation and setting the relation. Probably not needed with GridFieldHasOneRelationHandler).

I think that a drag and drop interface for managing a relation is less intuitive than the check boxes. Drag and drop is more for moving things around, which doesn't really make sense in the context of setting relations. To have the moving side of things make sense, you'll need to manage two GridField with distinct lists with drag and drop from one to the other.

I thought of drag and drop because that's how the old widget area used to work in 2.4, and I always thought it was a great metaphor. On one side, here's all your stuff, and on another side, here's the stuff you've put on the page. Best of all, each list was mutually exclusive, so you couldn't choose a widget twice.

That solution, or one like it, would resolve two inherent limitations of checkboxes:

1) You can see immediately which records are included without thumbing through the grid
2) You avoid using a metaphor that has ambiguous meaning. In the rest of the world, checkboxes in a table are used to queue up a bulk action (e.g. Gmail). When bulk deletes become available for GridField, it will create a confusing UI.

I think at the very least the checkbox column should be labeled so that users know what the checkbox is for. It should also be clear that the user has to save the page to persist the checkboxes, because again, checkboxes on a table are not conventionally a saveable entity. Some kind of feedback when you check the box might help, such as adding the record to a separate list, like my WidgetArea example.

Maybe something more like an on/off switch. Something that stands out as different than the checkboxes used for tabular bulk actions. All I know is, I've implemented dozens of ManyManyDOMs in the last few years, and I've never had a client who didn't need it explained to him or her, and didn't subsequently need it explained again down the road.

It's a tricky thing to articulate in a UI. I think I know now why SS avoided implementing it in 3.0.

You could have multiple instances of the same widget in the same WidgetArea. No disjoint sets there.

As soon as you drop pagination, as you're suggesting, you don't scale. Sure, the checkboxes don't scale well either, but the pagination does let them scale in much the same way.

The checkboxes behave as bulk actions. You need to click the "Save relation status" button (in the screenshot) for it to be applied. Yes, it can be better explained, I just have no idea what to make the column title that doesn't make the column massively large, since it does only contain the checkbox.

This was part of the reasoning I'm planning on changing it so you toggle editing the relation and editing the records. So one would have the set relation checkboxes, the other would have view/edit/other batch actions.

Hi, GridFieldRelationHandler doesnot seem to work with 3.1?

Please confirm? thanks

I released a new version yesterday that includes 3.1 and IE8 support.

sweet mate, it works like a charm on 3.1...

ta..