support per controller configuration without requiring controller extension

So i originally wrote #17 as way of configuring options globally. I planned on finding some way to allow per section overrides.
#17 works for us now, as it allows everything to work as it previously did.

So moving forward, we have a couple of options.

I'll start with a quote from @vworldat on the PR as a way to get things going

This change does not allow for several bundles to hold static content at the >same time. For me this is a dealbraker. I want to be able to:

have content in several bundles/controllers
use different "settings" (e.g. base template) depending on the controller being used

This is easily possible at the moment, but not with your changes. What about changing the config to something like this:

c33s_static_pages:
    My\Bundle\Controller\MyController:
        content_dir:    Pages
        wrapper_template: something
        # ...
    My\Bundle\Controller\OtherController:
        content_dir:    Stuff
        wrapper_template: something
        # ...
    My\OtherBundle\Controller\MyController:
        content_dir:    Sites
        wrapper_template: something
        # ...

So that could work, but i do wonder if we really care about controllers? or do we actually care about pages ( and sub pages and directories). Also, are there options here that are actually bundle wide and shouldn't be overridden?

There are some other ways to possibly solve this.

We can support specifying templates and some other options with an event listener in a similiar fashion to FrameworkExtraBundle. It works with annotations, but the logic can still be used without it by setting the request parameters ourselves.

It would end looking something like this in your route config file.

my_route:
    path: /pages/*
    defaults:
        _controller: MyControllerClass
        _template: my_template.html.twig

Another alternative is the Dynamic Router used by symfony-cmf. This could be the best option, since it has route enhancers that lets you add whatever you want to the route parameters without making a mess.

The CMF Router
http://symfony.com/doc/master/cmf/reference/configuration/routing.html

The CMF Routing Bundle (for symfony integration):
http://symfony.com/doc/master/cmf/bundles/routing/dynamic.html

With the dynamic router we would implement it based on file tree(s) instead of using
a database.

[vworldat]

First: i LOVE the idea of using the CMF Router component. I really do. This is cool, modern engineering at its best. BUT.
On the other hand I'm asking myself if this is really necessary for something that can already be solved with 2 or 3 controller classes of less than 10 lines of code each in my existing projects.

I'm not against cool, state-of-the-art solutions (really, I love them!) but the pragmatic guy inside tells me there are more important things for me to work on than improving something that is actually easy to use and running fine.

The current solution is dead-on simple, has a very small amount of code and hardly any external dependencies at all. I know that it is far from being perfect, but I really don't see the benefit of putting countless hours of work into something that saves me 10 LOC per project. My customers don't pay me for that, they don't pay @c33s for that and probably won't pay you for it either (if they do - go for it!).

I really like the stuff you did for making a single controller instance configurable, so it will work out of the box for small projects with only 1 template dir. This is great and I'll probably be using it myself soon. For anything going further than that I don't see the payoff at the moment (this could change in the future!).

If you just want to do it for fun, feel free to try anything you like and if it turns out to be stable and easy to use we will accept any contribution for sure. For my part I just don't see the need at the moment.

Thank you for your great contribution so far, this is what I love about open source!

👍

Well in that case.. to keep it simple let me tell you what i want out of the bundle to see what we can do.

1. a controller class that doesn't extend from frameworkbundle that i can use as a service
2. ability to use markdown in templates
3. automatic resolving of nested pages (like the partial subfolder stuff) so i can just do

my_pages:
   path: /*

under a pages prefix and automatically map /pages/faq/somefaqtopic to %content_dir%/faq/somefaqtopic.html.twig (or markdown)

I'm not sure what we can do for #1 without writing a controller that duplicates some of the code we already have.

I guess we can extract the template resolver code into another class and call it from both.

[vworldat]

Regarding 3: this already works out of the box if you tell the router to ignore the slashes:

some_route:
    pattern:  /{name}
    defaults: { _controller: "SomeBundle:StaticPage:show" }
    requirements:
        name:  .*

Regarding 2: same requirement here, although I currently just wrap my content in

{% filter markdown %}
content
{% endfilter %}

This can easily be solved by specifying a base template that includes those tags I think.
Edit: the reason I use the filter tags is that there are always SOME pages where I don't want full markdown filtering because it would mess things up.

Regarding 1: the only thing I can come up with at the moment would be traits, thus sacrifying PHP 5.3 support (not an option for me unfortunately).

so i guess adding a new controller is the only option then.

for markdown though i was suggesting that files like page.md could be supported,

[vworldat]

Using the file extension to determine the content type is an interesting idea (and quite obvious once you think about it. Gee, am I blinded!). You once spoke about some kind of locator service. I still think this would be an interesting option, even when keeping the controllers we use now.

What about some service that is given a base path and some config (if needed) an can be asked to return some file name / content type object or (optionally) even the rendered content?

// The base path could also be passed as constructor parameter
$locator = new C33s\StaticPageContentBundle\Locator\ContentLocator();
$locator->setBasePath('path/to/templates/dir');

// check if page exists
$locator->hasTemplate('home');

// fetch page information like file name, format, locale, ...
// I think some lightweight object might be useful here
$pageObject = $locator->getTemplate('home');
// the same specifying a locale
$pageObject = $locator->getTemplate('home', 'en');

// render page
$content = $locator->renderTemplate('home');

// What I would also like when having such a locator service would be to scan the directory, 
// returning all available files. This would be awesome to automatically generate sitemaps!
$pages = $locator->getAvailableTemplates();

Is this what you had in mind?

Moving most of the logic into the locator service would also reduce the amount of code needed inside the controller, making the controller much easier to replace.

Edit: still not sure if this code should handle "pages" or "templates", but I think I prefer "template".

lemme thinking about it. was going to examine Symfony's own template locator first. It'd be easier to write if we didn't allow per controller content directory overrides. Can we keep that as a global option only?

[vworldat]

It could be a global option as in "the content directory is the same for all controllers" (e.g. always Bundle/Resources/views/Content), but I fear if there is only 1 content directory allowed this wouldn't be enough.

My use case is: in all my projects I have a WebpageBundle (frontend stuff, consisting mostly of static pages) and an AdminBundle (admingenerators, dashboard, static pages online help etc.). Each bundle uses its own base template, and so does the static content. So I cannot and also (for the sake of orderliness) do not want to mix all those static pages into 1 bundle.
Currently I'm using 2 separate controllers, each one having its own template dir (Bundle/Resources/views/Content). When using the locator, I would need 2 locator instances, each with another template path.

Let's see what you can find out about Symfony's locator service, perhaps it would be enough. The only restriction I can currently think of would be to only have 1 controller/content path per bundle.

was referring specifically to the relative path from a bundle (content directory), not only one bundle

[vworldat]

As said before, I don't see a big issue there. Could be fine!