There is already a bundle for it https://github.com/Bazinga/BazingaExposeRoutingBundle

This bundle could help you : https://github.com/Bazinga/BazingaExposeRoutingBundle

Edit: oups, @beberlei was faster than me :)

@beberlei, @willdurand: woah, very useful!

+1 for including this by default with 2.1 in a 'Symfony'/'SF' namespace.

@lmcd not sure it should be moved to a Symfony repo as it would require a core dev to maintain it.

Without something like this, many users will resort to hardcoding URLs for things like XHR requests, which is bad practice.

@lmcd They can use the bundle even if it is not in the Symfony namespace. The goal is not to move all bundles to Symfony but to let each bundle author maintain their bundle.

I'm ok to include this bundle into a Symfony repo but, as @stof said my opinion is not enough.
BTW, I can provide support for it as I'm using it a lot.

Yea of course, but this most definitely should be included or at least documented somewhere.
Whether this bundle exists as a 3rd-party bundle or not, most users will end up just lazily hardcoding URLs everywhere in their JS files.

@willdurand The point is that if it is included in a symfony repo, it means that a symfony core dev would have to maintain it.

@lmcd @fabpot promised us a yet-to-be-done official bundle website.

@stof An officially supported bundle website would be great. Some really great must-have bundles are getting really poor exposure. With a name like 'BazingaExposeRoutingBundle', I would never have discovered it without explicitly raising this issue.

I agree that ExposeRouting may not be the best naming.

@stof yep I understand.
Nevertheless, this kind of logic should be handle by Symfony2, it's an expected feature IMHO.

The naming is not the main problem, it's hard to say "expose your routing into JS in order to generate URLs in JS files" in a short bundle name :)

maybe JsRoutingBundle ?

The main problem with having commonly needed features in third-party bundles is that there will be high-chances for conflicts between these bundles.

Javascript isnt something the Framework itself should deal with it is a PHP framework, also this could be confusing when people use all kind of different javascript frameworks.

Here's a better way to reframe this issue (I'm just brainstorming here):

Perhaps Symfony should implement a standardised, extendable JS container which bundle authors can drop components into to expose Symfony functionality. Benefits of this approach:

• Core devs will only need to maintain a simple JS <--> Symfony bridge
• All JS-related bundles will be standardised, extendable and configured the same way

Before y'all flame, I know Symfony is (first and foremost) a PHP framework but it would be nice to have a common way of exposing Routing, Localisation, Assetic, Forms etc

exposing Doctrine in JS ? really ?

@stof: well.... no :P I was just reeling off a list of things off the top of my head.

I don't agree with "this is a PHP Framework and it should only handles PHP".
Go to www.symfony.com and you'll read "Symfony is a web application framework" so it should handles common tools in order to build web apps. Today, JS is widely spread in web apps and Symfony2 should deal with that IMHO.

As @schmittjoh said, to provide needed features as third-party bundles will create some problems. Now, Symfony2 is stable and provides a lot of core features, this is the "architecture part" of a framework. It's time for Symfony2 to provide useful tools, at least the "common needed features", as the "toolbox part" of a framework.

This is just my point of view so, please, don't flame me :)

@willdurand: my thoughts exactly

@wildurand then Symfony should provide the Routing generating facility in Javascript for Ext.js MooTools jQuery Prototype and so on? Otherwise why should we support one JS Framework but not the others?

@henrikbjorn Absolutely. That's why the JS part (in case we are talking about my bundle) should be rewritten in pure JS.

Still think this is wrong. Also how should we decide what bundles are general enough to be in core? For some payments are a general thing so should this be included? The strong thing about Symfony is its Community and it is easy to create 3rd party bundles and if they are well written and used they will quickly become a defacto bundle, this is what have happend with FOSUserBundle and SonataAdminBundle.

You are comparing features with business logic. The topic subject is about a JS URL matcher.

@willdurand The annotation support for routing is not provided in the core but in a shared bundle too. This makes things more easy to maintain as you can release a new version of a bundle without needing to release a new version of the framework. Thus, it allows having different maintainers instead of asking Fabien to maintain all existing bundles (this is a reason why AsseticBundle has been moved to a separate repo maintained by Kris)

It is really the same thing :) Okay some websites does not use Javascript and therefor does not require this feature, but some does and do require this feature. Also some use javascript without using Ajax and does not need this feature. What basket of theese 3 categories do you think is the largest?

To be honest I think having a container of some sorts written in pure Javascript would be ideal as for example bundles could add things to it that will be then available to the Javascript part of the website.

This could be configured in the framework with something like:
javascript_toolbox enabled: true lazy: true

Where enabled is obvious and lazy sets if the loading of Javascript 'assets' should be done on page rendering or via Ajax.

Think about translations for example, or routing. These are the problems I'm working with right now and it would be useful if something like this would be available in order to have less wheel reinventing for each user and help bringing more good standards to the web.

@schmittjoh well basically yes. But i am okay with it being there because the majority of people hosting websites uses apache. You cant really say the majority of people needs to be able to generate routes through javascript ?

Majority being >50%, I'd say yes - the majority of large Symfony2 projects will at some point need to get the URL for another page via JavaScript.

+1 for this, if not adding it to the core can't the BazingaExposeRoutingBundle come with the standard edition?

@lmcd quoted from your comment: Majority being >50%, I'd say yes - the majority of large Symfony2 projects will at some point need to get the URL for another page via JavaScript.. This does not talk about your projects.

Why close this? I think that routing is sufficiently isolated that we can build a JS framework agnostic solution. We are not interacting with any DOM element, or do any other fancy animation stuff. In such cases, I think it makes sense for the framework to provide a generic solution even if not everyone is using it. We have other code in Symfony2 that not everyone uses, and we will always have such parts.

So, why not?

I closed it because of the douchy Symfony purists gettin their nickers in a twist and shooting down the idea at every opportunity. If you're +1 for this, give the issue a fresh start in a new thread and maybe it will get a better reception.

Ah I just noticed it was reopened :)

I think you should cool down. The person most "hostile" to other people opinions are you in this thread. I think its totally legitimate to question adding stuff to core/SE. But if you feel that this is an attack by purists then maybe yes you should refrain from interacting with OSS projects in general. But overall I guess what we are seeing is just the normal communication barrier people experience when they do not know each other and have to communicate from one screen to another. So I think we will all manage to work productively in the future even if we have somewhat have failed in this thread (at least to this point).

All will be good :)

@lsmith77: +1

Let me start by saying I understand your need not to hardcode URI in your client side application code: good for you, not a lot of people do that :-)
This does not however mean that we need to add a second component to do the same job we already do in PHP. That only creates more of the same code that should be maintained putting a strain on our resources.
If you design your application well it works with and without javascript.
The DOM should be your data-layer to communicate/configure routing in your client side application, not the other way around.

@marijn You dont read all of this discussion... quoting @schmittjoh:

I think that routing is sufficiently isolated that we can build a JS framework agnostic solution. We are not interacting with any DOM element, or do any other fancy animation stuff. In such cases, I think it makes sense for the framework to provide a generic solution even if not everyone is using it.

@stloyd, I did read the whole thread including that part and it doesn't make sense to me... I realize that we could build a standalone non-fancy utility that could do a fine job generating routes. My argument is that this seems redundant as we can (and in my opinion should...) use the DOM to communicate these routes to our javascript code and let our existing PHP codebase generate them.

A little beside the point, but meanwhile you can workaround hardcoding URLs like this:

Twig

<div id="some-url"
        some-attribute="{{ path('some_route', { 'someParam': 'someValue' }) }}"
        style="display: none;" />

JS (using jQuery)

var someParam = 'someValue',
    url = $('div#some-url').attr('some-attribute').replace(/someValue/, someParam);

$.getJSON(url, function (data) {
    // Process user data here
});

(I needed to contribute something so that I'd get notifications on thread updates, grin)

helmer commented just now
A little beside the point, but meanwhile you can workaround hardcoding URLs like this

Exactly the point but instead of using .replace the right routes should be communicated to your client side application. If those can't yet be generated because they have yet to be created (by some REST call) via XHR than the result of that call should include the reference to the resource. In my opinion it is not necessary to create an (expensive) routing component for the client side.

@marijn Damn, you beat me to it by a minute, but I gots example! Anyhow, using .replace is just an example if your routes are dynamic (ie, you have 10 images which have a click event against same route, differing in some parameter value) and mostly it is not really needed, agreed. Adding 10 different DOM inhabitants might pollute too much ..

But lets not get carried away, what can you have against a bundle to do this in a more convenient way (albeit expensive, though this can be benchmarked only later)? And, it certainly is necessary, at least for @lmcd and @Bazinga.

I am a bit towards not cluttering core nor even SE with it - include it if you want, overlook if not interested, that's what bundles are for mmh?

@helmer This is not a proper solution and things could be better with a clean API, I think.

To all others, consider what @schmittjoh said at the end. Don't flame other guys because you are using or not this kind of feature.

@stof, @lsmith77 & co Please, reconsider the real problem which is to include or not new features and I don't speak only for the ExposeRouting bundle. This bundle works fine as a third-party bundle and I'm happy for that :)

Envoyé de mon iPhone

Le 27 juil. 2011 à 22:08, helmerreply@reply.github.com a écrit :

@marijn Damn, you beat me to it by a minute, but I gots example! Anyhow, using .replace is just an example if your routes are dynamic (ie, you have 10 images which have a click event against same route, differing in some parameter value) and mostly it is not really needed, agreed. Adding 10 different DOM inhabitants might pollute too much ..

But lets not get carried away, what can you have against a bundle to do this in a more convenient way (albeit expensive, though this can be benchmarked only later)? And, it certainly is necessary, at least for @lcmd and the Bazinga guys.

I am a bit towards not cluttering core nor even SE with it - include it if you want, overlook if not interested, that's what bundles are for mmh?

Reply to this email directly or view it on GitHub:
#1827 (comment)

Some references:
http://pjax.heroku.com/ A jQuery Ajax HTML5 History plugin.

+1.
SF javascript object to handle some stuff like routing would be nice :D

I've a javascript bundle to handle automaticaly constraints of a form too. An unique twig filter added in a template. (not yet on git)
We can make a small javascript object helper with some useful fonctionalities.

I agree that it is a common problem that there is a lack of a feature that allows JavaScript to somehow dynamically access the routing. Normally I do something like declaring a JavaScript variable with placeholders like $$id$$. This, however, is far from optimal and I'd like a more flexible way of doing this.

However, I agree with @henrikbjorn, that this does not belong in the core of Symfony. Having JavaScript generated by the server side php framework seems odd to me. Instead I think it is up to the project to decide which approach is the best in the individual case.

I think this issue should be solved by a cookbook article instead of implementing the functionality into the Symfony core itself.

Last, I regret to see that an issue such as this is turned into a flame war. Please - use the energy on solving problems instead of herassing each other.

@fabpot What do you think here: looking at integrating the JS generator in the core or keeping it as a separate bundle ?

One aspect that hasn't been mentioned yet is that there'll be different editions than the SE in the future. Down the road there may be a more Ajax-heavy edition that might include the ExposeRoutes bundle by default.. at least that's how I understood the concept of editions. I'd be perfectly happy with a JS-clean core, bundles for everything, and editions for getting started quick..

Rock on.

I agree that there definitely is a need for this functionality, I've had to resort to using .replace and some placeholder before, both in Sf1.x and in Sf2.

However, the functionality apparently exists, I just didn't know about it. It might be a good idea to include it in the SE, depending on how many projects would make use of it, but in my opinion, this is mostly an issue of communicating the existence of the bundle.

It would be nice to have some kind of official bundle website, where this presumably would get much exposure. However, I believe that a simple cookbook entry would also serve this purpose. If we have a cookbook entry regarding how to generate urls from within Javascript referencing the bundle, that would very effectively communicate the existence of it.

Well, I gave the bundle to the FOS organization: https://github.com/FriendsOfSymfony/FOSJsRoutingBundle.
I cannot do more to increase the visibility of this bundle, a cookbook recipe could be nice but I don't have the time to write it at the moment. If you want to contribute by writing a recpie, I'll be glad to read it...

BTW, you can visit www.symfony2bundles.org to find existing bundles.

I do know about Symfony2bundles.org, I did find the bundle there before reading this actually :)

However, when I was writing the code where I needed it, I didn't know it existed. Had there been a cookbook recipe, I would have been much more likely too. I'm not saying there's much more you could have done, it's not like we should have a cookbook recipe for every bundle, just that in this case a cookbook recipe is a good way to raise awareness.

As for writing it, I would be glad to, when I have the time, but that's not in the immediate future :)

Hows about a note with a link in the routing documentation?

Sure, that would probably work well too.

I think over time the "bundles" section on symfony.com will expand, and several of the FOS bundles are good candidates to be included:
http://symfony.com/doc/current/bundles/index.html

I agree that this is a quite common need but IMO, it does not belong to the core. After looking at the bundle, it would mean adding a bunch of code; also, the core should not be tied to any JavaScript library. As a bundle already exist and does the job, I think this is more a documentation issue. I've created a ticket (symfony/symfony-docs#796) to add a note about this somewhere in the book/cookbook.