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
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 fo
> 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 %}">{% tr
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, mig
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 {{ b
