Support optional parameters in routes.

[petforsberg]

According to a SEO specialist I work with (and we want to build our CMS with use of CMF), there is a need to use parameters in routes, which are no routes themselves, but only used in controllers.

Normally, Routing-Auto-Bundle creates a routes built up from "path-unit", e.g.:
domnain.com/category/article
could correspond to /routes/cms/category/article Rout object.

With parameters however, there is a need to add some information to a controller in a way that was easily achieved in standard Symfony2 - when paramters are passed to a controller, e.g.:
domain.com/category/article/{page}

This is a basic example. But perhaps some might need also different cases, like:
domnain.com/{category}/article/{page}

where both category and page are just paramters - variables passed to a controller. (Is it possible in Content Repository based routes? I hope it is...).

Perhaps more sophisticated things are also possible? Example:

domain/category[-]{theme}/article[-p]{page}
i.e.
Route is: /routes/cms/category/article
And the pattern for a route is: domain/category-.../article-p...
"..." respond to a parameter, so finally in this case controller would get $theme and $page variables.

But at the moment the most important is the first case (the one with {page} at the end of an url), if the others are too complex.

[dantleech]

I think this should be easy enough to implement.

However -- are your Pages Documents? Or properties on your Article document?

If your pages are indeed documents, why not map the auto routing to the pages instead?

[petforsberg]

For the moment, I didn't choose a final solution. I'm still thinking of it. Which case you would recommend?
The idea is to split an article's content into a separate elements (no matter how they are stored in DB - as a separate records, or as a one block-string, which is then separated in controller?). The reason for separating is to have no html (or even alike, e.g. bb-code), and other formatting-related things ([img], [ul], [strong], [p] and so on) in the text. I thought up the solution as mentioned splitting all elements into separate "records" (if we wanted to refer to RDMBs). Now I wonder what is the best way to achieve it in content-repository based systems? Should I split it into children-nodes after .../category/article/[elements], where elements are no routes, but just "blocks" of an article? Or there is a better way?

I think pages shouldn't be documents (nodes). This is because editor in CMS might want to have possibility to easilt modify a content of many pages. E.g. move one part (paragraph) from one page to another.

[dantleech]

I would be tempted to make the "elements" children of the article as you suggest and then map the auto routing to those child elements. This would make the most sense from a routing point of view I think.

So

/cms/routes/articles/my-article/page-1
/cms/routes/articles/my-article/page-2

Where my-article would have a mapping to an Article document, and page- to a Page document.

btw, If you want to try out the new version of routing auto it would be really helpful, as we want to release it soon :)

The docs are in this PR: https://github.com/symfony-cmf/symfony-cmf-docs/pull/511/files
and this is how I upgraded my website: https://github.com/dantleech/dtlweb/pull/5/files#diff-b2907ca9e4d809552e5cac8d1755b843R1

[petforsberg]

Thanks a lot! Yes, I think this makes the most sense in content-repository world. (I just still think in a relation-db way).

Then, the other Page elements (paragraphs [p], images [img], and the other formatting things) could be just then child-nodes of the Page, but without being involved in a Route Objects (because they are not separate things, but relate to a Page only).

Thanks for docs reference. I can see that quite much change, like config labels (no more existing/non-exiting actions...?).

[dantleech]

No, no more non-existing actions. If there exists something at the destination we use a "conflict resolver" (i.e. auto increment).

But the biggest plus is the redirect routes - when you change the name of an article (for example) the old route can be turned into a redirect to the new route, which is great for SEO :)

It does require the bleeding edge version of PHPCR-ODM however..

[petforsberg]

Yes, the thing with changing articles names was one of those SEO specialist recently mentioned. Nice feature.

[petforsberg]

One more question: is Routing Auto able to manage / respond to domain names?
For example: wikipedia.org -> /cms/articles/main
and en.wikipedia.org -> cms/articles/main-en
?

[dantleech]

No, currently that feature is not implemented.

[petforsberg]

Can I leave a request for it? It's quite often used, e.g. for blog.domain.com etc.

[dantleech]

Yeah you can .. but given the use case you provided you would be better to route based on the domain + the uri, and not just the uri on its own.

e.g. it would be better to treat en.wikipedia.org/cms/articles/main as different from www.wikipedia.org/cms/articles/main if you see what I mean.

I'm not sure what the status of domain based routing is, @dbu?

If that functionality exists, or if we create it, then we can support it in RoutingAuto

[petforsberg]

@dbu busy I guess.

I found his answer at stack overflow: http://stackoverflow.com/questions/23744815/how-to-add-a-phpcr-odm-referencemany-field-to-sonata-admin
Thanks - this is something I needed as well for my app.

Now I'm at the stage where I can add children (i.e. pages) to the Article from within Sonata Admin - thanks to the code example in Block Bundle as suggested by dbu (otherwise I'm not sure if I was able to do this - it seems there's no much documentation on Sonata's PHPCR, isn't it?).

Now, Routing Auto creates a route for Article, but it doesn't for Pages. In fact, I don't need separate routes for pages. I think having routes for pages of an article is pointless - since they're just numbers (e.g. category/article-title/3 - for page 3 of the article), and problematical (the information of the page number would be doubled up then - i.e. in the page Document, and in the corresponding route object).

So I decided that probably the best way is to use optional parameter ({$page}), and pass it to the controller.

So the present request for the parameters feature is that they could be optional, and if not provided in the url, then e.g. the one from controller's is used.

Example of the controller's action's definition - it could look like the following:

    public function indexAction($contentDocument, $page = 1)

For the url: category/article/{page}
I.e. if user enters category/article url (without explicit page number), he gets the first page of the article, because default $page = 1 would be used in a controller.

[dbu]

hm, i thought i had answered here, sorry.

anyways, if your route document has a requirement on the domain, it will be taken into account. @benglass was working a lot on multidomain. we made it possible for RoutingBundle to pull in routes from different roots (e.g. a domain specific root and a default root shared for all domains). you can build on that, but maybe ben has some more input?
i guess right now the RoutingAutoBundle can not generate routes in different trees, and i would not know how to decide that - unless you could use the admin domain to set the root path for routing auto accordingly?

[petforsberg]

This feature is the most important one I think, since it allows to have a nice paginator feature with PHPCR nodes and Route Auto bundle. Would it be possible to have it implemented in the closest S CMF release? (If not, please let me know, I will then try to find some workaround for now).

[dantleech]

well, we have just released 1.0.0 (like 2 hours ago). So the next release isn't going to be very soon. But you can easily implement the solution we come up with here in your app and remove it when we release next.

@dbu @lsmith77 @wouterj ftr - what is the policy with non BC-breaking feature additions? Should they be in the major release cycle?

[lsmith77]

new features will go into the next minor release, aka RoutingAutoBundle 1.1

[dbu]

well, we have /just/ released 1.0.0 (like 2 hours ago). So the next
release isn't going to be very soon. But you can easily implement the
solution we come up with here in your app and remove it when we release
next.

if we have enough interesting features, i see no problem releasing 1.1
next month already. we do not need to sync all cmf bundles, if there is
a good reason.

what is the policy with non
BC-breaking feature additions? Should they be in the major release cycle?

http://semver.org/ says a minor version (aka 1.1) can have new features
as long as there is no BC break. we did not always follow that strictly,
but i think we should aim to do it. major versions (aka 2.0) are for
large rewrites and for all BC breaks - adding a method to an interface
or changing a parameter in an interface. changing the signature of a
public method, remove a config option, anything that makes existing code
not work after upgrading.

[dantleech]

Opened #152 which is more to the point as this issue is quite long and confusing now.