[WIP] Added Templating Helper for PHP templates

[wouterj]

fixes #61

[wouterj]

not sure if this is a correct name, but I don't think cmf_extension is the correct name.

[dbu]

should it maybe be cmf_core ?

[wouterj]

yeah well, I think I prefer cmf then. As 'core' doesn't add much information and core is just another name for 'default things' which is also what 'cmf' only means.

[dbu]

seems good to me. is the name of the twig extension important? i mean, does anything rely on that?

this PR will collide with #59 but i will manage to fix that :-) lets merge this one first.

[dbu]

btw, we started requiring the symfony PR header - please use it when creating PR to make them more clear

[wouterj]

The getName function for the Twig Extension is not relevant, as long as other filters and functions aren't using it. (you can get the extension by calling $context->getEnvironment()->get('extension name') inside another extension).

But the name is important in PHP templates, as that's the only way to get the helper:

<a ...><?php $view['extension_name']->getPrev(); ?></a>

[dbu]

but should we not use cmf_core then, to follow the principels of least
surprise? the other extension is cmf_block. though we could argue for
just cmf here too, dunno. as we are core, i don't fear name collisions.
you fixed it so you get to pick the name :-)

[wouterj]

Hmm, all functions has something to do with documents, so we can call it documents. That somehow follows how the frameworkbundle handles templating helpers, the name should not be explicitely related to the bundle name. But that means cmf_block should be blocks and that causes some inconsistency with sonata_block (which also should be blocks).

What about overriding (if possible) the sonata block helper with the cmf helper (which also provides the methods of the sonata helper. When we combine the sonata bundles with the cmf bundles, we can make this a lot easier and just have one helper class for the blocks.

tl;dr

• I think blocks and documents are the most logic names for PHP template users, as they are already used to use the slots and actions helpers.
• To integrate this into the cmf, we can extend SonataBlockHelper from CmfBlockHelper (which we will rename to BlocksHelper). We register the BlocksHelper as the blocks templating helper and advocate the use of that helper instead of the sonata block helper, to be feature compatible when we merge the sonata bundles.
• We call this helper documents

wdyt?

[dbu]

i agree with extending the sonata block helper and overriding it to provide one combined helper, that sounds logical.

calling this one documents however smells like too risky of name clashes to me. afaict there is no way to change the names (unless you extend the class to overwrite the method, and make the setup somehow pick the right class) so i am quite a bit afraid of name clashes.

[dbu]

and documents also has the drawback that in the long run this probably will be about "entities" too. i'll try to get some input from the mailinglist.

[wjzijderveld]

Considering the slots and actions, I think blocks makes sense.

Not sure about the documents as well, I think that you shouldn't make it about documents in your templates, but about content (in whatever way it may be stored).
So content crossed my mind, but that might be to generic again...

And again we can find this phrase to be correct :)
There are only two hard things in Computer Science: cache invalidation and naming things.

[dbu]

i thought the phrase goes |There are only two hard things in Computer
Science: cache invalidation, naming things and off by one errors.|

what if we would just call the extension "cmf" instead of "document" or
"content"?

[wjzijderveld]

Works for me as well, it's just a bit less descriptive, but in the end that is what it is.
It would leave the option open to add stuff to that extension not directly related to content/documents.

[wouterj]

If the stuff is not related to content/documents, it should go in another templating helper. If you look at the templating helpers in the FrameworkBundle you can see a lot of helpers. Helpers aren't related to a bundle, but to a feature. That's why I also think cmf_core isn't a correct name.

cmf is the name I already used in this PR, I can live with it :)

[dbu]

ok, if we say we keep cmf as name, is this ready to merge?

[dbu]

ping

[wouterj]

Yes, it's mergable afaics

(actually, I don't know if the tests pass, you forgot to register the travis hook?)

[dbu]

oh btw, do you also do a doc PR about php templating?

[wouterj]

Yes

[lsmith77]

the service configuration also needed to be updated 25f3955

[dbu]

ups, thanks. do you think we can activate travis on PRs here?

[lsmith77]

its on for everybody
http://about.travis-ci.org/blog/pull-request-testing-for-everyone/

.. but sometimes there are simply delays