Is this useful enough for core?
On Mar 24, 7:42 am, "SmileyChris" <smileych...@gmail.com> wrote:
> For a while I've been thinking that it would be nice to have a tag so
> you could re-use an expression in a template.
> I did one up and put it onhttp://www.djangosnippets.org/snippets/132/
Regards,
Aidas Bendoraitis [aka Archatas]
On Mar 25, 8:00 am, "Aidas Bendoraitis" <aidas.bendorai...@gmail.com>
wrote:
> Wouldn't it be more convenient not to have the closing {% endwith %}?
Perhaps, but rather than "dirtying" up the context, this keeps the
variable nice and encapsulated.
> On 3/24/07, Baptiste <baptiste.gou...@gmail.com> wrote:
> > For me, yes, but I miss the "and" :
> > {% with article.name as name and article.title as title %}
> > But it is an useful tag.
If you wanted to do this, you could just open another with tag. Apart
from a saving few characters, is there an advantage to complicating
the tag?
is just definitely awful.
;-)
If this were to go in, I think comma-delimiting multiple "assignments"
would make more sense than using 'and':
{% with article.name as name, article.title as title %}
This mirrors Python's import statement:
import math as x, urllib as y, os as z
{% for product in products %}
{{ product }}
{% with product.purchases.count as purchases %}({{ purchases }}
purchase{{ purchases|pluralize }}){% endwith %}
{% endfor %}
I would like to see a tag like that. The fact that snippet #9
and #124 deal with the same problem shows the people need/want
it.
Django should have a tag like that before everybody implements
their own different solution.
cu Arvin
--
Arvin Schnell, <asch...@suse.de>
Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Snippet #9 is quite different. It's providing arbitrary expression
computation, which is out of scope for the core templating language, but
is a useful third-party add-on for some people. Limodou been maintaining
that for quite a while now.
Chris's snippet #132 looks a bit nicer than #124. The "ifvalue"
construction in #124 looks like it's trying to do two or three things at
once. If I wanted that, I'd use Perl.
I'm personally a bit indifferent (which is not the same as "against"
before anybody gets riled up) to the arguments about "saving typing",
since all editors have decent auto-complete these days and it's just a
slightly longer name if you don't have aliasing. However, on a related
topic, it's easy when writing things like object.person.count to create
repetitive queries (there's no reuse of that queryset if you type the
same thing later). So I was thinking in idle moments today about how
possible it would be to add transparent caching to templates. It doesn't
seem to be impossible, although I need to sit down with a pen and paper
and scratch my head a bit more to work out the details (for example, you
need to have a way to mark some tags/filters as volatile so that
something like the "random" filter doesn't behave identically to the
hypothetical "always the same" filter).
Regards,
Malcolm
I actually the the {% with %} tag is a better choice for this --
"explicit is better than implicit" -- and after fooling with {% with
%} a bit, I'd say I'm +0 on this. Barring any serious objects (from
Malcolm or anyone) I think this should go in.
Chris: can you work up a patch in case we decide to check this in?
Jacob
Sweet; thanks.
I'm gonna wait a couple of days for any objections from Malcom/Adrian,
but unless I hear any I'll add this shortly.
Jacob
I have no objections. I'm +0 on the feature.
Cheers,
Malcolm
On Mar 27, 2:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Mon, 2007-03-26 at 17:06 -0500, Jacob Kaplan-Moss wrote:
I've done a patch to the "with" tag be able to accept multiple
assignments without the need to nest many with tags, look the
following example:
{% with complicated.var.name1 as name1 and complicated.var.name2 as
name2 %}
{{ name1 }}, {{ name2 }}
{% endwith %}
I reopened the proper tag: http://code.djangoproject.com/ticket/3826
and attached the patch.
The people here talked about separate many assigments with a comma or
an and, I prefer the "and" because it was easy to implement, if you
like the comma I can change it.
Best regards to you!