Yii2: support urlmanager in Javascript side

[spiritdead]

well i think a lot people have problems with this board, when need work with ajax,forms,etc

i see this GIT, is hard migrate this to the native js yii2 ?

https://github.com/ains/Yii-JSUrlManager

can add this enhacement ?

[SilverFire]

Url::to() is based on UrlManager rules. It means that we should expose all the url rules to the client side and I'm unsure whether this idea is good since it leads to full disclosure of URL rules. On other hand security through obscurity does not work, so developer should take care about proper requests filtering to any URL.

[samdark]

There's no issue security-wise.

[spiritdead]

i know sam but in what site i can submit this enhancement,etc and the board of the route is important :S

[SilverFire]

As I've said security through obscurity does not work, so admin board protection with URL hiding is not a protection at all. But I'm still worried with this, because beginners might not know about this feature at all and use hidden URLs for some sensitive actions.

[samdark]

It's not the case to care about.

[unclead]

probably related to #7649

[TerraSkye]

If somehow we an have the lazy loading principle that way only the url rules that are manualy set or checked against the server are loaded

[resurtm]

@SilverFire

It means that we should expose all the url rules to the client side and I'm unsure whether this idea is good since it leads to full disclosure of URL rules.

Even if I agree with @samdark regarding we must not care about someone does security through obscurity (security ignorance is not something you guys core developers should care about), a real implementation would allow to control of what rules are exposed, and what not.

As an example of how it could be handled: https://symfony.com/doc/master/bundles/FOSJsRoutingBundle/usage.html

# app/config/routing.yml
my_very_secret_route:
    pattern: /admin
    defaults: { _controller: HelloBundle:Admin:index }
    options:
        expose: false

UPD: I think this feature is a must in the framework, as Yii2 already positioned and advertised as a full stack framework having JS/client side solutions/parts (i.e. yii.activeForm.js, etc.) too.

[klimov-paul]

I suppose we should discard this issue as it should be coupled with particular JavaScript framework.
At 2.1 we are plainning to decople JQuery from the core and I do not like the idea we should proceed towards the way of JS code improvement.
I prefer developer to choose which JS framework to use: React, Angular, JQuery and so on.

Unless particular imlementation of this feature can not be made at raw JavaScript level - it is better to put it out of the Yii scope.

[samdark]

Agree.

[resurtm]

@klimov-paul

as it should be coupled with particular JavaScript framework

Can you elaborate in details how it would be tied up to some particular JS framework? When implementing this we can just use plain ES5 without using jQuery or other similar libraries (BTW: jQuery is library, not framework). What's the issue with that?

How I see it would be just a several (maybe single) function(s) declared in global/window JS scope. They would simply receive route name and parameters, and return some URL. Do we really need here to be tied up with jQuery or something similar? I think no.

These URL generator functions could be used everywhere: Vue.js, Angular, plain old jQuery, etc.They would be JS library/framework agnostic.

[resurtm]

Please investigate and examine this implementation of FOSJsRoutingBundle for Symfony 2+: https://github.com/FriendsOfSymfony/FOSJsRoutingBundle/tree/master/Resources/js

It doesn't use any library/framework, and simply does the job.

[resurtm]

At 2.1 we are plainning to decople JQuery from the core

I'm voting to drop asset manager support at all in 2.1+, or at least decouple and move it to the external optional extension. I don't like I need to disable it in every single project I'm crafting now, since I never used it at all: why would I need it, if Gulp or even Webpack does this job much much better? Kinda weird backend framework enforcing me to do that.

[samdark]

I'm voting to drop asset manager support at all in 2.1+

That's totally separate issue.

[samdark]

Assinged to 2.1.x. Could be done but certainly not a priority.

[klimov-paul]

Can you elaborate in details how it would be tied up to some particular JS framework?

Many JS libraries have URL routing built-in. Usually it is coupled with AJAX in order to create 'one page' sites. The first one in this list is Backbone (nowadays it is almost forgotten).
If I wish to create a URL manager for JS code I wish it to be bound to the JS framework AJAX routing rather then to abstract library.

It doesn't use any library/framework, and simply does the job.

It does not looks to be independent to me as it depends on Google Closure Library:

https://github.com/FriendsOfSymfony/FOSJsRoutingBundle/blob/master/Resources/js/router.js#L3-L6

I'm voting to drop asset manager support at all in 2.1+, or at least decouple and move it to the external optional extension.

I can see no sense in it: it is your choice whether to use it or not. Asset manager and asset bundles system allows you to add at least a first JS include to your page. You may not need anything else - it is your will. I can see no harm in its existance.
I can say same thing for mutex classes in the end - it may be I do not need them, but it does not mean we should exract it to the separated repo.
This issue is not the place for such disscussion, see #8452.

[klimov-paul]

Speaking about separated extensions, I think this feature should be implemented as separated extension.
Personally I never needed it and consider it to be a bad practice.

Also its implementation will bring other problems in the future: translating simple URL rules like

'<controller:\w+>/<action:\w+>' => '<controller>/<action>'

can be simple. But yii\web\UrlManager allows creating of complex rules with complex logic, which may involve database access and so on. For example: I may create a CMS, which allows random pages creation with unique URL keyword assigned to them, so for accessing such page following URL will be used:

http://example.com/page-slug

How will JS library contact the Database to check if particular page-slug exists or not?

Starting implementation for such feature we should support everything - otherwise developer will consider feature is not working.

[samdark]

Separate extension is a good solution. If it will be good, I'm fine linking to it from the guide.

[resurtm]

@klimov-paul

Asset manager and asset bundles system allows you to add at least a first JS include to your page.

Uh, is it really necessary? It triggers additional classes eating PHP memory, consuming time, etc. What is wrong with <script type="text/javascript" src="/app.js"></script>? Why would we need to trigger asset manager to register just a freaking single JS file? :smile:

[resurtm]

Starting implementation for such feature we should support everything - otherwise developer will consider feature is not working.

Please check my comments above, I mentioned there is no need to expose all the application rules to the client side.

[resurtm]

Ok, there is no point in additional discussions as this has been rejected.

[samdark]

@resurtm there are two separate discussions going on. The one about dropping assets should not be discussed here for sure (and it's not rejected). The one about routing is, indeed, rejected to be implemented in framework core in favor of community extension.

[klimov-paul]

It seems you do not listen.

Uh, is it really necessary? It triggers additional classes eating PHP memory, consuming time, etc.

here I have told you:

• first of all, this issue is not the place for such discussion
• second: unless you invoke AssetManger, e.g. you put your scripts in 'good old' way using <script type="text/javascript"></script> no class source code will be included no object will be created, no memory will be consumed.

Please check my comments above, I mentioned there is no need to expose all the application rules to the client side.

Here I have told you that half-solution is not a solution.