Currently, if you add any "Content pane" View to page which uses Fields, Content or Table to display, it'll allow the user to switch between them.
However, it'd be great to be able to provide a way for certain Views to opt out of this functionality!
Ideally, I think this would be another checkbox in the "Allow settings" configuration on the View. But I'm not sure how easy/possible it is to alter that form and store our data there.
If that's not possible, it'd be great to have some kind of whitelist/blacklist in the Panopoly Magic configuration to say that certain widgets are for sure allowed and others aren't. Or at the very least a hook to make that determination!
Comment | File | Size | Author |
---|---|---|---|
#6 | panopoly_test-display-type-2468371-6.patch | 56.37 KB | cboyden |
#3 | panopoly_magic-display-type-2468371-3.patch | 7.93 KB | dsnopek |
Comments
Comment #1
dsnopekIt totally possible to get this on to the "Allow settings" form! That part was actually pretty easy. I've been having more trouble disabling the 'Display type' form element without breaking all sorts of other things, which I'm still working on...
Assigning to me because I'm working on this now!
Comment #2
dsnopekOk, here is a patch that implements the functionality. Removing the 'Display type' form element was problematic because there are a bunch of form elements that depend on it via '#states'. I tried coming up with a way to only set '#states' conditionally if we were using 'Display type' but otherwise hide via '#access' but it turned into a big spaghetti mess that didn't really work. :-/
So, this patch takes a much simpler approach, which always puts 'Display type' on the form, but turns it into a 'hidden' input if we don't want to see it, so the '#states' stuff still works. However, this is a hack and not really ideal. In future we need to really untangle this code so we can do "the right way".
This also had the side-effect that the code to check if the 'Display settings' fieldset was empty and hiding it no longer worked (because it wasn't really empty, the elements where just
#type => 'hidden'
now). So, the patch fixes that logic as well!This still needs tests...
Comment #3
dsnopekHere is a new patch which adds a hook_update_N() function and a patch to panopoly_test which adds tests! This works for me locally - need to run on Travis-CI with the full test suite next.
EDIT: Here's the Travis-CI build: https://travis-ci.org/panopoly/panopoly/builds/58603108
Comment #4
cboyden CreditAttribution: cboyden commentedThe test patch looks like it also moves tests into a subdirectory of features - is that going to be repeated for other tests?
Comment #5
dsnopek@cboyden: Eventually, per #2334333: Reorganize Behat tests by feature and role! I snuck it in here because it was getting convoluted with all the different .feature files that related to panopoly_magic.
Comment #6
cboyden CreditAttribution: cboyden commentedLooks like the patch to panopoly_test needs a re-roll. Attached.
Comment #7
cboyden CreditAttribution: cboyden commentedThis is looking good. I think the default handling of column headers on table displays (i.e. always showing headers if they're present in the view) is what we want, but there may be some other opinions.
Comment #9
dsnopekAwesome, thanks! Committed. We can address the header configuration in a follow-up if necessary.