I personally think having JS code generated from Django template is not necessary better than having JS globals. Actually I finding it is more problematic and keep causing issues:
* app.module.js has to be manually collected and being placed before some Django template generated JS code: https://github.com/openstack/horizon/blob/master/openstack_dashboard/templates/horizon/_conf.html#L26-L34, because of it, we have to do multiple section like this: https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L307-L316 for each sub_path under the app/ folder. We cannot add app.module.spec.js app.module.mock.js, app.moduls.mock.spec etc besides app.module.js since they won’t be auto-collected, and we have to always keep this in mind, otherwise when it is not auto-collected, it is quite hard to figure out why. Actually this happened to me today when I try to add app.module.mock.js and app.module.spec.js. * app.module.js has some hacking-ish code at https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/app.module.js#L62-L66 , it quite smell to me. * I am not a big fan of this code: https://github.com/openstack/horizon/blob/master/openstack_dashboard/templates/horizon/_conf.html#L34-L46 either, it looks like conducting surgery on JS with django’s template language. * I haven’t figured out what causing the issue with this patch yet: https://review.openstack.org/#/c/199319/ . But I suspect that it is also related to the hackings. I tried with a pure html file with the libraries and app.module, it works fine. * Having _conf.html is a quite odd thing to me, it seem that there is no reason for it except for hacking (correct me if I am worng). Ideally there should only be _script.html being responsible for populating <script> tags and should no inline js code. To me, a pure data or pure data object (an object that has no its own methods) generated from python/c#/java/php/ruby/nodejs is ok, but code, especially angular code generated from code template is a bad thing. They are always the biggest headache I have to deal with. One elegant solution is that, let’s have one and only one pure data object wrapping all the data that we need to collect from the python environment, and set it in the global, or hook it on an existing global variable, `horizon` for example, so we won’t pollute the global space. Richard - constants are independent to each other, a constant can not be defined by using other constants regardless it is a string or a function. To use such a function, we can only define angular providers, and angular provider cannot be used to define routing with ngRout/ui-router. This is one issue. Another issue is, when using a basePath, you have to inject in at least two dependencies and you have to go to all the place there using basePath to do the changes, all the tests will be broken, I already tried something similar, I don’t believe that could be possibly simpler that the current solution even we will never consider client-side routing. Thanks, Sean From: Richard Jones <[email protected]<mailto:[email protected]>> Date: Fri, 17 Jul 2015 10:58:35 +1000 To: Thai Q Tran <[email protected]<mailto:[email protected]>> Cc: Tripp Travis S <[email protected]<mailto:[email protected]>>, Shaoquan Chen <[email protected]<mailto:[email protected]>>, Borland Matt <[email protected]<mailto:[email protected]>>, Cindy Lu <[email protected]<mailto:[email protected]>>, Lyle David <[email protected]<mailto:[email protected]>> Subject: Re: Alternative way to set webroot and static_url Hi all, I'm sorry to say I've not been following the window / STATIC_URL / WEBROOT stuff very closely, so I'm not sure exactly what the problem is that's trying to be solved. In this specific case, it looks like the linter is complaining about access to the window global, which seems fair enough. Switching to a config/constant combo using $windowProvider seems like a good move to me. As I've previously mentioned in passing, having the config step set up a function to calculate paths (rather than using string concatenation all over the place) could also be a good move, as it'd reduce the complexity of a bunch of code, I think. Richard On 17 July 2015 at 10:50, Thai Q Tran <[email protected]<mailto:[email protected]>> wrote: Hi All, I was playing around with the webroot thing today and found a different way to set webroot and static_url. https://review.openstack.org/#/c/181095/54/horizon/static/framework/framework.module.js Using these 2 methods outlined, we can actually get rid of static_url and webroot from global space. As far as I know, legacy has only one file that uses static_url in source code, which we can eventually replace with an angular equivalent. Anyway, just wanted to bring it to your attention, have a good weekend everyone. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
