Consider dropping the jQuery dependency about fosjsroutingbundle HOT 17 CLOSED

Yes I'm working on improving this.

from fosjsroutingbundle.

@schmittjoh : did you work on this issue ?

from fosjsroutingbundle.

Well, I started on this, but my solution would put a dependency on the JMSSerializerBundle; so, I wasn't sure if it would fit into this bundle.

However, if you think this is not a problem, I can submit a PR for it.

from fosjsroutingbundle.

Why did you use the JMSSerializerBundle ?

Yes, you can submit a PR to let me see your work :)

from fosjsroutingbundle.

I've copy/pasted some code as a POC:
6699242

This is far from finished, but just to give you an idea how it would look like. Basically, that code is using some utility functions of the Google Closure Library, and is intended to be compiled with the Google Closure Compiler which replaces these utility functions with raw javascript.

If you think this is good, I could work on migrating the rest of the proprietary code.

from fosjsroutingbundle.

Do we really need JMSSerializerBundle here ? It should be doable using the core Serializer component to remove the dependency. The work should be doable by serializing the RouteCollection as JSON and doing a method call instead of using a bunch of connect method calls inherited from the sf1 plugin way to do.

I don't have issue about using Google Closure as long as the bundle contains the compiled version and the doc explains how to develop using it.

from fosjsroutingbundle.

I don't like the idea to add a dependency to the JMSSerializerBundle.

from fosjsroutingbundle.

Yeah, that's why I didn't continue to work on this.

Anyway, I need it for my set-up as I compile the Javascript aggressively and some of the properties might be renamed so that for example "pattern" becomes "zA" or some other gibberish stuff. The serializer then needs to take that into account, and that's not doable with the core serializer.

from fosjsroutingbundle.

Well, we should probably use a less aggressive compiling in the bundle to be able to use the serializer. Does it seem good for you ?

from fosjsroutingbundle.

It's fine for me if we don't type hint the serializer and let people provide
whatever they want (core serializer vs. bundle serializer).

Then I can use aggressive mode in my code and for the bundle we can use a
simpler approach.

On Tue, Sep 6, 2011 at 11:10 PM, Christophe Coevoet <
[email protected]>wrote:

Well, we should probably use a less aggressive compiling in the bundle to
be able to use the serializer. Does it seem good for you ?

Reply to this email directly or view it on GitHub:

#5 (comment)

from fosjsroutingbundle.

I'm +1 to serialize the RouteCollection in JSON and to connect all routes in one method call.

from fosjsroutingbundle.

I would be a good idea to have a common interface between both serializers (your SerializerInterface as it is a subset) to allow type-hinting the argument when we only use the serialize and unserialize methods but I'm fine with avoiding the type-hint.

from fosjsroutingbundle.

Yes .. I am now +1 on moving the JMSSerializerBundle interfaces to core.

from fosjsroutingbundle.

I'm +1 as well even if I'm weightless :p

BTW, try to keep things simple for the JsRoutingBundle.

from fosjsroutingbundle.

@willdurand, what do you think about the draft assuming that we remove the type hint. Do you think it's getting too complex?

from fosjsroutingbundle.

Sounds good but, as I never played with Google Closure, I'll hope you'll comment your code and you'll provide a compiled version out of the box :) If we remove the jQuery dependency, it's not to add a new dependency.

So, if there is no regression, I'm definitely +1 as I like the usage of the serializer in the response.

from fosjsroutingbundle.

Closing this in favor of the PR.

from fosjsroutingbundle.