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.
