GridField add relations via checkboxes & some other GF usability comments

[Mark Huser]

Hi all,

I've been implementing a SS3 site hopefully not set to go live too soon :-) but it's been a great exercise in gauging administrators' usage and feedback.

Primarily, the link existing functionality of a relation management GridField is great but on a small list of possible options is slightly unwieldy especially in a situation where the user doesn't know exactly what they want to add – my suggestion would be a list of options with checkboxes ala Uncle Cheese's Dataobjectmanager module for 2.x as a Config option. I think this speaks for itself but happy to elaborate if needed.

Secondly, and this is mainly to have this confirmed – when adding or viewing a relation via the GridField, then returning to the page via the breadcrumbs, any further actions in any GridField instances on that edit page result in a double "Not Found" notification. Anyone come across this?

When editing/adding relations, a confusing situation is the "Back" button in the breadcrumbs – should this not return the user to the page they had come from rather than dumping them back on the edit home page?

Overall, the feedback regarding managing data via the Gridfield is very positive so kudos on the great work so far. Beta 3 is also a great step forward in terms of simplicity.

Cheers,

Mark.

[Sam Minnée]

Primarily, the link existing functionality of a relation management GridField is great but on a small list of possible options is slightly unwieldy especially in a situation where the user doesn't know exactly what they want to add – my suggestion would be a list of options with checkboxes ala Uncle Cheese's Dataobjectmanager module for 2.x as a Config option. I think this speaks for itself but happy to elaborate if needed.

This would be implemented as an alternative component for the gridfield.  I'd probably use GridFieldAddExistingAutocompleter as a starting point and replace the autocompleter with one of those fancy dropdowns?  Patches welcome... ;-)  There's actually already a ticket about this, but it's not slated for 3.0 - http://open.silverstripe.org/ticket/7275

Secondly, and this is mainly to have this confirmed – when adding or viewing a relation via the GridField, then returning to the page via the breadcrumbs, any further actions in any GridField instances on that edit page result in a double "Not Found" notification. Anyone come across this?

Sounds like a bug, plain and simple.  Could you figure out a test-case and post a ticket when you have?  This kind of thing really need to be our focus now.

When editing/adding relations, a confusing situation is the "Back" button in the breadcrumbs – should this not return the user to the page they had come from rather than dumping them back on the edit home page?

It should go one level up the stack.  One thing I've noticed is that search fields and pagination are lost when you go back.  This is a bug and I've logged it here: http://open.silverstripe.org/ticket/7416

[spierala]

Hello all,

I also just created a new Silverstripe 3 Site. It´s great in general! but the thing that I missed most was the possibility in the Gridfields to add new relations to existing Data Objects via just checking a Checkbox like in former days in the HasManyComplexTableField.

It´s completely true what Mark Huser says that the link existing feature is not effecient if you could select from hundreds of Dataobjects - the user just does not know what to search for.

Hope there will be solution for that.

Kind regards,

Florian

[Uncle Cheese]

The HasOne/HasMany/ManyManyComplexTableField (or DOM) were some of the biggest usability hazards I've seen In SS to date, and I'm glad they've been thrown into the dustbin of history. Not only did they make an outright mockery of the inheritance chain, but I can't tell you how many clients had to be instructed to check off records before saving, or had to be told that there is no bulk edit/delete function, despite the fact that there are checkboxes preceding the data of each row, which is a convention that is used in tabular data UIs everywhere else. They were clunky and unorthodox to say the least. Good riddance.

The need is much better served by coupling the GridField with a dropdown field or ListboxField for setting the relation. Your users will thank you.

[Ingo Schommer]

Hey Mark, Aaron, I think you both have valid points.

From a core perspective, I think we're getting a bit better (stricter?)

on providing useful baseline tools, rather than the kitchen sink.

And the GridField is a good example of this way of thinking.

Its a solid API which encourages meaningful extension,

and provides reasonable default functionality.

The "type to add" pattern scales to 1000s of records, so is a good default. 

A checkbox UI might be better suited for smaller datasets,

but I don't see any obstacles for anybody implementing this as a module. :)

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/FZQo0WsTdQ8J.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Uncle Cheese]

I agree. I love that GridField has such an amazing API, but the downside of putting extensibility over the "kitchen sink" approach is that without a solid dependency management system, it gets really laborious to bootstrap your site. By the time all these features are covered by modules, I'm going to need 10 different modules on my application just for GridField alone. They produce a lot of clutter in the filesystem, but more to the point, you have to go get these things every time, and keep them up to date indefinitely.

Who's that guy that was overseeing making the module page more user friendly? Can't remember his name. Some American guy... liked to complain a lot about free software. I wonder what he'd say about this.

[Ingo Schommer]

:D Yeah, don't know who that might've been.

Once we have composer integration, it'll be a simple as copying your own composer.json

over to your new project and running "composer.phar update".

This JSON file can be placed in a skeleton setup, with modules added depending on your needs.

From a core perspective, I think an increasing amount of modularization (and hence dependencies)

is a necessary evil. We can't just put everything in core to reduce "filesystem clutter",

because by that we commit to maintaining it indefinitely, at a high standard.

Which we can't do for every possible feature permutation out there :)

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/oksRvzibiwMJ.