Custom Block Attributes1 user found helpful
* For example, what if you wanted to add a 'Title' to a Slide Show Block?
* What if you wanted to associate a thumbnail with a Content Block for special treatment?
* Maybe you need to tag your block with some meta data?
My solution is creating Custom Block Attributes. The same way you can dynamically create and associate attributes with files/collections/users, I want to be able to create / associate attributes with blocks.
I've got a quick solution prototyped (see attachments), but it unfortunately requires me to hack the core. I'm curious to see if there's enough desire for this functionality to try and push it to core?
So, I'm looking for two things: If you would like to see this functionality added, please voice your support.
If you have an idea of how to make this functionality better / expand on the concept, please comment as well.
[3:29pm} Mnkras-Laptop: I was thinking of combining it with custom templates [3:29pm] Raverix: Interesting... [3:29pm] Raverix: I like the idea of integrating it with custom templates. [3:29pm] Mnkras-Laptop: [3:29pm] Mnkras-Laptop: in the custom template dialog [3:30pm] Mnkras-Laptop: like having a controller for custom templates that extends the block controller [3:30pm] Mnkras-Laptop: and having a form.php that is pulled to the custom template dialog [3:31pm] Mnkras-Laptop: and a db.xml [3:31pm] Raverix: I'm sold. [3:31pm] Raverix: I'd love to work on something like that. [3:31pm] Mnkras-Laptop: I was also thinking of instead of having the custom template thing as a menu item [3:31pm] Raverix: But I don't want to have to re-implement it everytime C5 upgrades the core. [3:31pm] Mnkras-Laptop: to integrate it into the add/edit dialog [3:31pm] Raverix: Put it in the edit block, absolutely. [3:32pm] Raverix: Of course, if you did that, you add a whole new level of complexity.
Then again, it sounds like you're talking about block attributes being associated with block instances and not block types. Is that correct?
If the user is expected to be able to select from a series of custom templates, I think they can be expected to fill in the fields when prompted for them.
> * What if you wanted to associate a thumbnail with a Content Block for special treatment?
> * Maybe you need to tag your block with some meta data?
Isn't that what overriding and editing block controllers and templates is for? If you're talking about this being a part of the standard editing UI, I'm not sure that kind of functionality belongs in the hands of the typical site maintainer.
Or, have the ability to 'tack on' extra attributes to your blocks.
You don't have to create a new page class in order to add new attributes to a page, this is what I'm trying to emulate for blocks.
Ok, I looked at the images you posted, and I do see value in what you're proposing - at least for very knowledgable types. It would simplify the process of enhancing a block for developer types.
However, I'm still not convinced it has a place in the standard editing UI. If there's one major complaint I have about C5, it's that there's just too much to fiddle with for the "regular" site owner (feature rich or feature laden, depending on your perspective).
> You don't have to create a new page class in order to add new attributes to a page,
> this is what I'm trying to emulate for blocks.
So then, are you talking about associating specific attribute types with blocks in general, with block types, or with block instances? I'm just wondering how you envision the attribute type associations being set up.
Since obviously, the attributes wouldn't be displayed until you added them to the template, I think that makes for a very compelling argument that these two things should be tied together.
For example, let's say you wanted to create a callout box which was simply a content block, but has a 'title' field which is treated specially and needs custom markup around it? Well, you would have to write a custom template, so when the user selects that template, being prompted for a title makes perfect sense.
In this situation, it would be on a per custom theme basis.
I haven't actually tried it yet myself, but it seems to address at least some of the same issues - at least in terms of allowing developers to quickly create custom blocks which have specific pre-defined types of content and which end users can then easily create and edit.
But that, I think, poses a bit of a problem - at least for the typical user - whether it's part of an enhanced template selection dialog or a separate menu item and dialog. I see the potential for confusion on the user's part if they have to go through some alternate UI (apart from the standard block editing UI) in order to add/edit/associate some additional data/content with the block. I can see someone asking, "Why do I have to edit/configure the block, click the update button to dismiss the editing dialog, and THEN click on that same block again and choose a different menu item in order to enter MORE information about the block I just edited?!!"
Why is it now with the current system, to add a block with a custom template you have to add a block, add all your information, and then save, and then click the block, and open the custom template menu to complete the process?
I'd love to hear any insight you have into making this an integrated process. Moving the custom template UI into the add/edit dialog would be a step in the right direction. Maybe a tab on the same box? Maybe the fields are added to the top? the bottom?
1) It attempts to address the inability in C5 to quickly make custom blocks. Right now, you have to do it by writing custom code.
2) It adds more blocks to the system than I think are necessary. (Imagine Content block with title, content block with thumbnail, image block with title, sub title, caption, and alt tag)
3) If you want to make a modification to that block, you need to modify the existing block with code, you cannot modify it using the package, (reference the same issues above, yes, you can do it, but it's not a efficient solution),
The solution I'm proposing would overlap some of what this package does, but in my opinion, offers greater flexibility.
Here's the difference:
* Designer Content Block creates new blocks.
* My solution enhances / augments existing blocks.
The inherent benefit is that you don't need to mess with the existing code, saving a lot of time, and C5 can continue to evolve and not break your additions.
I am not for certain but I think it would be possible to have c5 core simply attach that tab to all add block popups and store the info separately but still attached to the block id and just automatically extend it to all blocks old and new.
I would suggest that a better UI for it would be an additional item in the popup menu (under "Custom Template"), not in the block editing window itself. Block attributes should just be one consistent interface (like how the page attributes UI is), not something that needs to be designed by the block author. Maybe it could be combined into the "Custom Templates" popup item so that popup menu doesn't keep getting longer... because when you think about it, a custom template is really just one kind of block attribute.
The complicated part of the code (besides the editing UI of course) would be making sure this stuff carried through when a block is aliased from the Page Defaults or is copied via the Scrapbook (or is just an alias in the scrapbook), etc. etc.
All that being said -- as much as I like this concept, maybe all that's really needed it 1 textbox for the "title" (and the title would be out of the way and optional of course) -- that would seem to cover most use cases I'd think.
Also, I've since learned that Areas already have attributes -- so in your theme code you could do this:
$a = new Area('Main'); $a->setAttribute('some_attribute_key', 'some_value'); $a->display($c);
Getting that attribute from within the block... I'm not exactly sure how (I'm sure it's not hard, just haven't done it yet because the "block name" is enough for my uses).
But I don't think there are attributes on blocks (other than the "block name", which isn't technically an "attribute" in the C5-object-model sense -- it's just a special text field).
I just revisited this today, and with the new architecture changes 5.6, this can actually be accomplished entirely within a package. As of this evening, I've got BlockAttributes 100% working, saving, updating, etc.
I've got an interface set up with the custom templates dialog. Each customs template can optionally provide a list of attributes that it wants filled, which will show/hide based on the current template. I'm still working on the UI, might try a nicer integration with the edit dialog, but what I have now is workable.
My biggest use cases that I foresee:
1) augmenting existing blocks with extra attributes for display.
2) adding meta data to blocks, (filtering, tabs, ect)
3) meta blocks - blocks composed entirely of attributes.
If you can think of any other use cases, please let me know so I can try and design them IMO the architecture.
I plan to work on this a bit more, and will release an alpha version shortly, and would appreciate some help testing if anyone's interested.
On another thread I have been campaigning for the block cache decision (currently read from variables set in the block controller) to be open to the user interface, so block level caching can be selectively enabled/disabled. Maybe your block level attributes can play a role in this.
For your testing: what happens to block level attributes attached to a content block and display of them in a view template for the content block when the block cache is enabled?
As for the cache, I hook into the update methods of the Block Model so that saving attributes to blocks triggers the same cache refresh that editing the content does.
Sounds like you're close to having it ready for use.
Is your code available anywhere? I'd be very interested in both testing for you and contributing/helping you finish it up.
How did you fair with this? Is it a package you could release on the marketplace?
I'm really excited and would love to use it ASAP.
We'll give it a go in our next project for sure.
Thanks again for your awesome work and help on everything C5!