Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

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

Open
benglass opened this issue Sep 27, 2013 · 1 comment
Open

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

benglass opened this issue Sep 27, 2013 · 1 comment

Comments

@benglass
Copy link
Member

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
Copy link
Member

dbu commented Sep 27, 2013

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants