Regardless of the pros and cons of particular javascript frameworks,
which we could argue about forever - we need to address Eugene's
proposal.
I would like to see what usage of his proposal in a template would look
like - that seems to me to be the most important thing.
Fundamentally, I'm with
Hmmm, obviously, when I say
" We clearly have the talent and the focus to do a good job"
I don't mean to take credit for the wonderful work of others, or to
imply that Eugene does not have the talent or focus to do a good job
with this.
After all, I'm just a noob who hasn't contributed anything
Georg,
I agree with you that we should approach this issue by building just
what we need in a practical and incremental way,
so +1 for that.
But are we sure we want to build our own javascript framework from
scratch?
There are two opposing forces here: the effort to develop and maintain
our ow
hugo wrote:
[snip]
>
> 1) I'd prefer "manager = PersonManager('name_of_manager_attribute')
> over the "an attribute named objects will magically turn into objects_"
> - the default for the name should be 'objects', but if there already is
> an attribute named that, the validator should barf. And
Robert,
I understood it wasn't implemented yet. Thanks for the clarification -
it looks good!
Robert,
Thanks again. I can see how I can acheive what I want to acheive with
simple_tag.
I'm not sure that I understand your first example though.
Is the list of url patterns passed as parameters to inclusion_tag
supposed to be searched for a match to decide which template to use?
It seems I
xt is also
True).
If nobody objects (rather, if people think it's a good idea), I may try
to submit a patch for this.
Thanks.
Robert Wittams wrote:
> Colin Howlett wrote:
> > Robert Wittams wrote:
> >
> >>Sorry, I just can not work out what on earth you are actuall
What Amit is proposing with his
{% render partialURL%}
tag is extremely similar in concept to the
{% include_url %}/url/with/{{ param }}/{% end_include_url %}
tag that I proposed (and provided code for above). my reasoning for
using separate start and end tags was to ease the construction of
Robert Wittams wrote:
> Sorry, I just can not work out what on earth you are actually trying to
> achieve - too many instances of the word 'generic'... A concrete
> example would be best.
Robert,
Sorry, I guess I wasn't communicating very clearly.
What I want is something like the {% include %
At risk of hijacking the thread, I've been struggling with something
similar (if I understand patrick correctly) Basically, I've been trying
to come up with a way of including re-usable 'pagelets' or
sub-templates into a parent template that are rendered with their own
local context generated by g
Hmmm, looking at ticket #925, I think I prefer that solution - never
mind, just ignore me.
I'm a little late to this, but it should be noted that it's not
currently impossible to make the request available to the context, just
a little messy. I wrote the following middleware which does it (forgive
the rotten code - it was just a proof of concept)
from django.core.extensions import Djan
12 matches
Mail list logo
