search

symfony-cmf / block-bundle

Extends the SonataBlockBundle to integrate with PHPCR ODM
https://cmf.symfony.com
20 stars 51 forks source link

Ability to embed block services that aren't stored in PHPCR #143

Open benglass opened 11 years ago

benglass commented 11 years ago

It would be good to be able to embed a standard sonata block service that is not stored in PHPCR into a PHPCR document's content area so it is handled by cmf_embed_blocks or a similar twig filter.

The use case would be if you want to show 3 featured products from a product database on the home page. You could embed a product block service (service id sonata.block.service.project in this example) in the content using syntax like

%embed-block|sonata.block.service.project|end%

Additionally you would want to be able to specify options to the embedded block so you could tell it you want to show only featured projects and limit it to 3

%embed-block|sonata.block.service.project &featured=`1` &limit=`3`|end%

I'm not sure how useful the options would be for the cmf stored blocks but it seems like there could be a use case.

I already have a working example of this in a completely separate filter which is based on the cmf_embed_blocks filter. I would be interested in hearing from folks about

  1. Is this a feature we want to add

  2. Should it be a separate twig filter or supported by the existing one?

    Since the syntax would be the same except we'd have to determine whether we are dealing with a service id or a path which should be a matter of simply asking sonata block's BlockManager if it has/supports a block with that service id and if not fall back to current behavior of loading from cmf. Additionally not requiring 2 filters to be executed seems to be a performance gain.

  3. Thoughts on the options format (using ampersands is less than ideal as they can get htmlencoded and then you have to handle those, the example I gave is based on the modx snippet syntax. Wordpress doesnt use the ampersands or the backticks for example.
dbu commented 11 years ago

i think we really should extend the handling of the current filter rather than add a second filter. so a PR would be appreciated. (though i want to only merge that after 1.0 is tagged stable, this would go into 1.1 - if we keep adding features we will never see a stable release. really sorry about that)

checking if this was a block id and fall back to cmf sounds good to me. for the parameter format, the & seem a tricky choice. vertical bars could be nice, but they might be hard to find on a keyboard for non-coders. maybe we can steal that from some wiki that has a nice syntax?