At the moment we are using a context provider and 1 block to place facets as block.
Some disadvantages of this are:
- No default sane title for a newly created blocks. It's "Facet block" by default, while we could use the facet name instead.
- New workflow, which is a bit strange to grasp (create block, select context)
- This new workflow is not widely used (e.g. when you create a views block display, core creates a separate block for each views block instead of using context providers)
- No context visible if only one facet exists (this is a core bug, and is likely to be fixed in 8.1 or higher, but at this moment its not really acceptible)
Some advantages:
- none I'm aware of.
I discussed this with EclipseGC and Swentel on irc
[23:26:24] <StryKaizer> EclipseGc: for Facets we are using contexts to define facets in a block, as you suggested in Barcelona. I'm wondering what the advantage is compared to creating a block per facet? (At this moment, it is not that clear which facet is which in the block UI overview, which can be solved by moving to separate blocks instead). However, if there are good reasons to use context, we'll just need to find another way to fix UX
[23:27:57] <EclipseGc> StryKaizer: Ok, so perhaps we miscommunicated, we use contexts when the block requires an object of some sort to operate (and that object is swappable) but something like a particular facet (say date or publish status, etc) could likely be done via plugin derivers
[23:28:06] <EclipseGc> StryKaizer: does that make sense when I describe it that way?
[23:31:26] <StryKaizer> hmm, not 100% clear, sorry :)
[23:36:09] <StryKaizer> EclipseGc: Do you think our implementation (1 block, context provides all facets which should be selected in the block config) has any advantage over creating a separate block per facet?
[23:37:04] <EclipseGc> StryKaizer: I’d have to look at the code
[23:38:00] <swentel> StryKaizer, if people create a good name for the block, they're fine no ?
[23:39:28] <StryKaizer> swentel: yes, but (and this is core atm, likely to change in 8.1 or so) contexts are not visible if only 1 context exists at this moment
[23:39:39] <StryKaizer> swentel: which is just weird for our usecase
[23:40:02] <swentel> StryKaizer, yeah, been 'bitten' by that sometimes
[23:40:12] <swentel> it's confusing sometimes :)
[23:41:17] <StryKaizer> swentel: views creates a block per view, which is kinda similar to our usecase. I'm guessing there's no real advantage for context for our scenario, which would fix UX (Blocks have a default sane name, now that default is "facet block")
[23:42:25] <swentel> StryKaizer, I'd personally vote for block per facet
[23:43:27] <swentel> StryKaizer, that was my initial expectation, took me a while to figure out I had to look/search for 'Facet block' when placing the block
[23:43:28] <StryKaizer> Same, if we dont loose any advantages I'm unaware of
[23:44:13] <swentel> don't know the code enough, but I bet you won't
Comment | File | Size | Author |
---|---|---|---|
#9 | create_a_separate_block-2639560-9.patch | 10.04 KB | borisson_ |
#9 | interdiff.txt | 739 bytes | borisson_ |
Comments
Comment #2
StryKaizerComment #3
StryKaizerComment #4
borisson_I think I agree, it shouldn't be hard to implement with a deriver either.
Comment #5
borisson_How about this?
Comment #6
borisson_This needed more work.
Comment #7
StryKaizerTested code and worked as expected.
I'd use the facet->getName() only here (so without "Facet block:"). This way it has a nice default title already. Core block titles also already have nice useable titles without extra info.
Comment #8
borisson_Sounds good. I'll fix that later and commit.
Comment #9
borisson_Comment #10
borisson_Thanks for the review. Committed.
Comment #16
borisson_is already committed, closing up.