Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

Elefant CMS: Dynamic Blocks and Blocks with Fallback

edited November 2012 in Framework

Hi Guys,

first of all Im super happy that my Embed Object Manager is merged into the master! It was my first contribution to an OpenSource project!

Here is my next project :-)

I started to extend the blocks app in order to have one or more blocks on a page wich will be rendered according to the page id. This will make our templates more flexible.

@jbroadway: you came up with this idea: http://www.elefantcms.com/forum/discussion/comment/815#Comment_815

{! blocks/index?id=[id]&type=sidebar !}

If a type is specified the handler will prepend it to the id and look it up. On the index page this would be index-sidebar, on about-us, about-us-sidebar, ...

If you want a default block to show up on every page with no block defined:

{! blocks/index?id=[id]&type=sidebar&hasDefault=true !} 

In this case default-sidebar is the next choice, but there would be a plus-icon next to the edit options to override the default block.

If you omit the hasDefault Parameter it's the same as hasDefault=false:

I prepared a gist for this: https://gist.github.com/4027520

What do you guys think about it?

Cheers betaman

Comments

  • I really like the combo of id + type to allow for multiple blocks bound to the id, but I wonder if a couple things could be improved:

    1. Could we simply improve the sub-expression support in templates to parse things like ?id=sidebar-[id] so we don't need two fields? I can see the name type causing confusion to some users wondering what types there are. It's a name that implies a pre-existing list of options. Defining custom id values could maybe avoid that.

    2. Instead of &hasDefault=true why not &default=sidebar where you specify the default sidebar id explicitly? That way you don't have to remember that it's default-sidebar and not sidebar-default and instead just see what it is unambiguously.

    Other than that I think this would make a great addition!

    PS. Congrats on your first open source contribution! I'm glad it's on our little project here :)

  • Yes this notation is much more intuitive. But I fear the sub-expression part is pretty regex heavy and I fear it's beyond me. Can you please help me with the regex stuff and I will do the rest.

  • Just committed a change to lib/Template.php that makes the variable substitutions more flexible, so you can do ?id=sidebar-[id] and it should work correctly now.

  • Great, thanks :-)

  • Hi guys,

    I used the flexible blocks in my recent project and i think it's pretty cool. (I will do my part of our deal asap :-) Meanwhile I got the crazy idea of dropping the body field in the admin/edit?page= altogether and put the whole content into the blocks. The admin/edit?page= would then be more a metadata editing area. The add button and the edit button (aka page settings/page options) could move to the toolbar.

    This could be advantage when our inline editor gets implemented, behause all the inline-editing logic stays at the blocks.

    Maybe there could also be meta Blocks which will stay invisible and hold data (eg headline/Teaserimage/Summary, or stuff for this

    What do you guys think about that?

    See you

    betaman

  • Hi,

    I comitted something to my new fork: https://github.com/betaman/elefant/commits/master

    I hope I got the Lock things right. Please let me know if you think its good enough for a pull request.

    Cheers Betaman

  • Just did a quick review so far. Once I have a chance to clone and test it I'll post back :)

  • Hi, i made a new commit, according to our discussion and gave the tooltipp css a tweak. If the tooltipp is longer than 100px it will get extra lines ...

Sign In or Register to comment.