On 18 mar, 13:43, sdcooke <sdco...@gmail.com> wrote: > I realise this doesn't apply to everyone but we've been coming up > against > this recently and every time I've looked at creating a JavaScript > version of > the URLs functionality I felt like it was overkill for our needs. 90% > of our > situations (again, might not apply to all!) could be solved by > attaching a > "data-" attribute to an HTML element. For example, if you're popping > up an > AJAX dialog box you could include the url on a button like this: > > <button data-url="{% url ... %}"></button> > > That way, you don't need to do any resolving in JS. Just thought I'd > mention > it here in case people come across this thread and unnecessarily start > adding resolver apps that they don't need.
Weird, I have missed this thread. But anyway, like sdcooke, that's also the way that we handle URLs in javascript. Attach a data attribute to the HTML node to which it applies, and read it from inside the javascript. It's clean. <td><a href="{% url accounts_edit_name %}" x:ajax-url="{% url accounts_ajax_edit_name %}">{% trans "Edit" %}</ a></td> Like gettext, a seperate, dynamically generated javascript file for URL resolving is not scalable to lange web applications. And further, I think that the urls and names of views are not meant to be exposed to the client. I don't want a visitor to be able to reverse engineer my website, and read all the possible URL patterns. Jonathan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.