Change the way urls are fetched

[zauddelig]

I would propose to wrap django.conf.urls.url so that the developer can get access to something like ng_url(pattern, view, name, namespace).

from django.conf.urls.url import url

def wrapper(*args,**kwargs):
    register_url_for_angular_use(*args,**kwars)
    # eventually one could do kwargs["name"] = "ng_" + kwargs["name"]
    # but that as pro and cons to be determined
    return url(*args,**kwargs)

Using this the developer is not forced to mess up with namespaces and seems more explicit, since urlconf would look like this:

from django.conf.urls.url import patterns, include, url
from djangular import ng_url
from . import views

urlpatterns = patterns('',
    url(r'^info.html$', views.info, name="info"),
    ng_url(r'^carousel.json$', views.json_info, name="json_info")
    )

Just a look and one is going to know what is going to be used by angular.

[jkosir]

Well that makes sense, but it somewhat complicates urlconf's unnecessarily.

I'm actually trying out a different approach atm, which seems better. Basically a wrapper view on server-side, which would get url name and arguments, reverse it and call appropriate view, then return result. That eliminates the need to load url regexes to angular and since all reversal of url's is done by django there are no problems with edge cases. Any thoughts on that?

[syabro]

@dasf +1

[zauddelig]

@dasf +1

The service would look like this if I did get it right:

function(url_data, $http){
    var get_url = function(){
       url = base_url +
               url_data.name +
               '/' + (url_data.namespace+ '/') || ''
       return url
    }
    this.get=function(params){
      /**
      *  params should be composed like this:
      *    {
      *      url_params:<object>,
      *      get_params:<object>,
      *    }
      **/
      $http.get(get_url, {params:params})
    }
    this.post=function(params,data){
      $http.post(get_url, {params:params,data:data})
    }
}

Only it would be hard to use ngResource then so that it should be implemented another service to be compatible with it (this could make sense since ngResource is an optional dependence while official).

[jkosir]

Yes something like that. I'm currently trying to implement this in a way it could be used like it is now. It might work by using the reverse function in request config, and using the request interceptors to change the url and add url name/params. Also changing the url might cause some problems, some extra testing will be required.

[zauddelig]

mmh so it should maintain the syntax $http().method(djangoUrl('name',params),config)

Maybe it would be better to have djangoUrl return an adhoc object so that one would have something like this:

$http(djangoUrl('name', params)).get()
$http(djangoUrl('name', params)).post(data)

//one could also do:
angular.extend(djangoUrl('name',params), refined_config)

This way $http would be initialized with the config data by djangoUrl service.

the same concept should apply to interceptors I think, while I've not played much with them one ultimately change the config objects, but doing so one end messing up with all the $http objects, so some flag would be needed.

[jkosir]

Yes I'd really like to keep the same syntax, at least for now, to maintain backward compatibility. Anyway I'll probably finally be able to do some work on this over the weekend.

[zauddelig]

Hello keep me updated, if there is anything I could help with tell me.