Nesting blocks about silverstripe-blocks HOT 10 OPEN

You would do something like:

class Page extends SiteTree {
    private static $has_one = array(
        'Gallery' => 'Gallery'
    );
}

class GalleryBlock extends Block {
    private static $has_one = array(
        'Gallery' => 'Gallery'
    );
}

class Gallery extends DataObject {
    private static $has_many = array(
        'Blocks' => 'Block',
        'Pages' => 'SiteTree'
    );
}

See relationship docs for more info

from silverstripe-blocks.

I would create a custom block type that is a subclass of Block. For the blocks nested inside that I would create a NestedBlock object which is a subclass of DataObject. I think no need for "nested blocks" to be subclasses of Block, the just have a data relationship to the parent Block

from silverstripe-blocks.

thank you! this should be in the official docs as a faq!

from silverstripe-blocks.

Sorry now I re read the answer, what if I want to create a Gallery that works either as a main block and a nested block? that is, you could add it directly to the page, or you add it to a column.

from silverstripe-blocks.

Then you'd want to consider abstracting your code so that it could be re-used for those two purposes. ie. you have a Gallery DataObject that can be added to a Block and/or SiteTree object

from silverstripe-blocks.

To add the Gallery DataObject to a SiteTree object, will it suffice to declare it into my yaml file? Wouldn't I have to reimplement all the Block interfaces if I extend the DataObject instead?

I'm doing a website with Elemental and found it super cool to have a block like an Image to be added both to a Column and a Page and know how to react based on that. But there is no blocksets feature and the nesting is not thoroughly documented. Would like to add a working example of that to Blocks as a skeleton for others to use, sort of like when you inspect the ContentBlock source to make your own.

from silverstripe-blocks.

I built a system with nested blocks. I wouldn't advise it based on the the current blocks module. The problem is less with blocks module and more with how SS handles certain relationships. It starts getting very complicated if you need to maintain controller functions, versioning, as well as searchability and tracking ancenstry back up to the root page.

It's easier if convert the Page to Block relation to a has_many and has_one. You loose reusabilty, but for most implimentions it's not so big an issue.

The changes coming (in SS4.0) to versionioned DataObjects as well as many_many realtionships should ease a lot of the pains.

from silverstripe-blocks.

Thank you for the comments, so have you explored how https://github.com/elemental/Elemental or https://github.com/Zauberfisch/silverstripe-page-builder do it? Do you think their implementation is also too weak to support nested blocks in a stable way?

from silverstripe-blocks.

As I said, the problem is less with the actual module more with the way Silverstripe Handles versioned many_many relations. Elemental uses a one to many relation so it may be better option (its basically what I converted blocks to be . It really depends on the key features you need. I haven’t tried Zauberfischs module.

On Nov 22, 2016, at 4:57 PM, digitall-it [email protected] wrote:

Thank you for the comments, so have you explored how https://github.com/elemental/Elemental https://github.com/elemental/Elemental or https://github.com/Zauberfisch/silverstripe-page-builder https://github.com/Zauberfisch/silverstripe-page-builder do it? Do you think their implementation is also too weak to support nested blocks in a stable way?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #107 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABm24XyeyRQ0HhNj1bjouAmzpHBJqpe3ks5rA2UsgaJpZM4KpFPp.

from silverstripe-blocks.

ZF's module is built on nesting from the ground up, he even mocked up a really interesting admin UI, not tried it.

I am using Elemental and does the job, has UserForms support (not tried it), has Translatable support (tried it), solved basic fulltext searching by copying everything in the Content field and hiding that up (I think the blocks tree traversal should be investigated a bit as I fear some deeper content doesn't get copied).

from silverstripe-blocks.