On Wed, May 4, 2011 at 12:38 PM, Jonathan Slenders
wrote:
>
> 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
> 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.
>
> x:ajax-url="{% url accounts_ajax_edit_name %}">{%
On 18 mar, 13:43, sdcooke 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
>
Hey Marco,
I have forked your library on GitHub and added the management command
to build a list of urls and output the file in the format that is
specified by django-js-utils.
https://github.com/Dimitri-Gnidash/django-js-utils
Cheers
On Mar 24, 11:37 am, Marco Louro wrote:
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already,
Ahh, I missed that from your original post.
I like that. :)
--
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
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already, but
It could just be a combo of both. There'd be one file for the
urlresolver.js, and a patterns.js. Interesting.
Now, could the patterns in Python be translated to Javascript properly? I'll
do some playing around today and see if I can come up with some basics. Even
if this doesn't land in Django
I think the biggest problem with translating the reverse() lookup is the
lack of kwargs and named capture groups in Javascript regex. So a pattern
such as: /page/(?P\d+)/ would not translate whatsoever. Then on the
Javascript side, we wouldn't be able to use: reverse('goto_page', [],
I currently handle this issue in a much easier way:
I've created an app which allows creating a context for Javascript (this
basically works like the template context processors do, calling defined
functions and combining its results into a dict). The resulting context
will be available in the
There also proposes the problem of selecting which urls are "published" in
this file and which aren't. Any ideas for that? I'm sure lots of people
wouldn't want their entire sitemap exposed to the public in one large js
file.
--
You received this message because you are subscribed to the
I might also add the script could literally be something that is created via
a management command and served via staticfiles.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
"dynamic" is a bit strong, but yes. A generated js script that, based on the
regex in your urlpatterns, provides functions that plug vars into url
templates... so yeah! A lot of the resolving logic wouldn't (read
"shouldn't") be needed so long as unique names are used for the views.
--
You
So you're basically proposing to write a Javascript library that is a
translation of URLResolver, and essentially have a dynamic "Javascript" file
that could be included that would contain your URL patterns? Just trying to
make sure we're on the same page.
--
You received this message because
Somewhat incomplete thought there -- once the urlpatterns have been
analyzed, the resulting chunk of generated js can be cached (where ever) and
served up statically, or inline in your templates.
--
You received this message because you are subscribed to the Google Groups
"Django developers"
Url patterns don't tend to change at runtime, right?
I don't think resolving urls one by one via ajax calls is going to work.
Reimplementing the resolve/reverse mechanisms in javascript - or better yet,
using the "native" resolve/reverse code to generate javascript functions
that take args
How could this even begin to be solved without incurring another http
request to resolve the url pattern?
The only way I can imagine it is if we had a generic /resolve/ path that
took some get parameters to return a full URL, or even it translate to a 301
redirect, but that'll get messy with
On Thu, Mar 17, 2011 at 7:44 PM, Marco Louro wrote:
> I don't really know how to approach this issue the best way, so I'm
> just going to be direct, I'd love to see Django provide support for
> django.core.urlresolvers.reverse (at least) on the client (in
> JavaScript).
>
>
On 17 March 2011 16:58, Carl Meyer wrote:
> Hi Marco,
>
> On 03/17/2011 10:44 AM, Marco Louro wrote:
>> I don't really know how to approach this issue the best way, so I'm
>> just going to be direct, I'd love to see Django provide support for
>> django.core.urlresolvers.reverse
Hi Marco,
On 03/17/2011 10:44 AM, Marco Louro wrote:
> I don't really know how to approach this issue the best way, so I'm
> just going to be direct, I'd love to see Django provide support for
> django.core.urlresolvers.reverse (at least) on the client (in
> JavaScript).
I think this is really
I don't really know how to approach this issue the best way, so I'm
just going to be direct, I'd love to see Django provide support for
django.core.urlresolvers.reverse (at least) on the client (in
JavaScript).
I'm pretty sure all who have needed to make AJAX queries have dealt
with the issue of
21 matches
Mail list logo