Re: Django urls in JavaScript
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 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 > +1 -- 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.
Re: Continued work on a django.contrib.formtools.wizard replacement
As I said before I'm +1 for this. I have to tests latest code against Django 1.3 to see if it handles browser's back button correctly. But django-formwizard is a great app, far better and more complete than current contrib's wizard. I have to apologize for not collaborating in building the docs for this app, I've been overloaded with work Stephan, sorry. Cheers, Miguel 2011/4/25 Stephan Jäkel > Jacob Kaplan-Moss wrote: > >> I'm +1 in theory. I need to spend some time going through your code, >> and I'll need to see some documentation on porting existing wizards to >> the new code (unless it's truly 100% backwards compatible). But in >> general I think it's a fine idea and something I'd love to target for >> 1.4. >> > > Based on the current documentation ( > http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/) > of the FormWizard, there are some things to change: > > - The "done" method exists in the new FormWizard but there is no request > argument, the request instance can be found in self.request. > > - the context variable names are prefixed with "form_" and there is no > "previous_fields" variable. (data is stored within the session or cookie) > > - Hooking into a urlconf has changed, a as_view method needs to be called, > because we use the generic class based views. > > - The "prefix_for_step" method was renamed to "get_form_prefix" and now > gets the form instance as an argument too. > > - The methods "render_hash_failure" and "security_hash" don't exist anymore > (because of the storage backends) > > - The "parse_params" method don't exist anymore but you can hook into the > get/post methods. > > - The "get_template" method don't exist anymore but there is the > get_template_names method from TemplateView. > > - The "process_step" method exists but has no request argument (the request > instance can be found in self.request) > > As you can see, many things changed but I think is reasonable if you look > on the improvements. > > Cheers, > > Stephan > > > -- > 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. > > -- 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.
Re: Django urls in JavaScript
> 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 %}">{% trans "Edit" %} a>
>
> 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
Just sharing thought here. Another approach that I use is creating an
"indirect" url and view that reads the url_name and args from
request.REQUEST, reverse the path, resolve the view and call it on
your behalf.
## urls.py
#
from django.conf.urls.defaults import patterns, url
urlpatterns = patterns('js.views',
url(r'^url_reverse/$', 'url_reverse', name='js_url_reverse'),
)
## views.py
#
from django import http
from django.core import urlresolvers
def url_reverse(request):
if request.method in ('GET', 'POST'):
data = getattr(request, request.method)
url_name = data.get('url_name')
try:
path = urlresolvers.reverse(url_name,
args=data.getlist('args'))
(view_func, args, kwargs) = urlresolvers.resolve(path)
return view_func(request, *args, **kwargs)
except urlresolvers.NoReverseMatch:
raise http.Http404
return http.HttpResponseNotAllowed(('GET', 'POST'))
Somewhere in javascript:
$.get('/js/url_reverse/', { url_name: "account_profile", args:
[username]});
Of cause, this approach exposes your url names to javascript. Some
people might not like it.
--
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.
Re: Django urls in JavaScript
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
> 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:
>
>
>
> 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.
{% trans "Edit" %}
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.
Re: Suggestion for improvement to template block/extends tags
Russ his solution is better indeed, but the content of the middle
block has to be defined in the child template, so it would become the
following:
a.html
{% block decorated %}first {% block content %}{% endblock %} last{%
endblock %}
b.html
{% extends a.html %}
{% block decorated %}left {{ block.super }} right{% endblock %}
template.html
{% extends (either "base.a.html" or "base_b.html") %}
{% block content %}middle{% endblock %}
Off topic:
The {% decorate %} template tag has its uses, but is indeed not
required here.
It is a design pattern that's commonly used in languages like
XAML.net.
It is more readable and compact than the only current alternative:
including a template and using {% extends %} inside the include.
cheers,
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.
