djng_all_rmi and djng_current_rmi template tags do not expand

[AncientSwordRage]

I'm trying to use this snippet of code, from the docs.

{­% load djangular_tags %­}
…
<s cript type="text/javascript">
my_app.config(function(djangoRMIProvider) {
    djangoRMIProvider.configure({­% djng_current_rmi %­});
});
</s cript>

(ignore the broken 's cript' - work's over zealous firewall)

And it's failing on the line djangoRMIProvider.configure({­% djng_current_rmi %­});, but if I put a console.log I get back "djangoRMIProvider [object Object], so I know the object exists. It just doesn't seem to like the .configure(...) part.

I think the tags are loaded (I had to use this hack but it prints out a debug statement to say it's loaded).

What could be causing this issue? I'm on Firefox 10 if it matters.

[jrief]

Into what does the templatetag djng_current_rmi expand? Just copy&paste it from the rendered html.

[AncientSwordRage]

@jrief They aren't expanding to anything. They're sat under my_app/templatetags/djangular_tags.py.

[AncientSwordRage]

It looks like it's happening as JS is trying to interpret `{% djng_current_rmi %} which itself isn't loading.

[AncientSwordRage]

This is the body of the same question/issue I posted on SO

I'm trying to use Django-Angular's djangoRMIProvider to give my angular app that sits on top of django access to some django methods.

The snippet I've copied in (and customised the my_app name), and added a console.log to is:

{­% load djangular_tags %­}
…
<scr ipt type="text/javascript">
console.log("djangoRMIProvider: "+djangoRMIProvider);
my_app.config(function(djangoRMIProvider) {
    djangoRMIProvider
        .configure(
            {­% djng_current_rmi %­} <!--errors here -->
         );
});
</sc ript>

It turns out that neither {­% djng_current_rmi %­} nor {­% djng_all_rmi %­} expand out to what they should.

I've gone as far as copying the Django-Angular file djangular_tags.py under:

my_app ↳ templatetags ↳ djangular_tags.py

And I'm certain that both my_app and django_angular (I had to rename the Django-Angular app djangular to django_angular as there is another package, Djangular, with the app name djangular - try saying that ten time fast) are in 'INSTALLED_APPS'.

I even used this dirty hack to force the tags into the builtins but either I've done it wrong, or it doesn't work (I do get errors saying it's looking in django.templatetags.my_app.templatetags.djangular_tags, which is not right, or other erros, if I put anything but my_app.templatetags.djangular_tags in that function call)

[AncientSwordRage]

@jrief someone has posted the answer on SO. The django templating engine isn't looking inside the config function's {}

[Ivaylo-Bachvarov]

Hi,

I was faceing the same problem today. djng_all_rmi returned an empty object.

urlresolvers.get_all_remote_methods was not resolving my url view, because it didn`t have a name. I put a name and everything started working.

get_all_remote_methods assume that your url has a name. But is a wrong assumtion because it is not required in django.

[adrienbrunet]

Thanks for reporting. We'll update the docs according to the SO answer. About the url name, we'll see if we can change the method.

Meanwhile, naming your urls is really handy to retrieve them via a reverse() call. (If you start to use djangoUrl.reverse() in your js, it will be a great help. :smile: )

[jrief]

Yes, the best solution for now is to use the djangoURLProvider. I already migrated all my apps to use it. However, this reported error must be a regression, in earlier versions it worked fine. So, or we get rid of this feature at all, or I have to dig into running code to search for the reason. What do you think?

[adrienbrunet]

I do not use this feature, I'm using djangoUrl too. Meanwhile, some people are using it, removing this feature could be quite harmful for them. But, updating the docs should help right? I mean, it works fine if we write it properly?

[jrief]

sure @adrienbrunet , you're right. But having to name=... the remote allowed methods was just something I wanted to avoid.

[adrienbrunet]

What we could do:

• deprecate this feature in the next release with deprecation warnings and docs to encourage using djangoUrl
• remove it in one more release
• for our current release, update the docs (I'm going to do it soon, at the same time than the "required fields asteriks" docs.)

Unless we agree to be a bit more disruptive and remove it directly in the next release.

Otherwise, we can still investigate and maintain that feature but I'm not sure it's worth the efforts. We're already lacking time...

[adrienbrunet]

Not using this feature. I still want to deprecate it for future versions. No further reports has been made on this issue though. Closing it for now. Docs has been updated.