On Tuesday, June 10, 2014 12:14:21 AM UTC+2, Russell Keith-Magee wrote:
>
>
> Hi Przemek,
>
> I'm not entirely certain I understand what you're proposing here.
> simple_tag, inclusion_tag and assignment_tag are all utility classes that
> you use to produce template tags; however, all the "native" template tags
> have their own implementations - which includes, for the most part, their
> own parsing infrastructure.
>
> Note that I'm not necessarily defending this arrangement -- In the past,
> this has been the cause of inconsistencies in argument handling between
> tags. However, it is the status quo, and it needs to be taken into account
> - if only because The side effect of this arrangement is that any custom
> template tags out there are relying on the fact that variable resolution
> *doesn't* happen in the render phase - at least, not in any automated or
> semi-automated way.
>
>
In my opinion those custom tags in the wild have to deal with this
situation already (if I understand you right). For example InclusionNode
with non-constant parameter (non-constant template name) will do the
parsing of included template (and nodes/nodelist instantialisation) in
de-facto render (global render) phase. If this is not what you meant, could
you please explain further?
> So - at a high level API level, what you are suggesting sounds
> interesting - *args and **kwargs are a powerful mechanism in python, and I
> can see how they might be useful in the context of template tags as a
> general feature - but I'm not sure I see how this would manifest in
> practice. The only two approaches I can see are:
>
> 1) a backwards incompatible change at the root level of template tag
> design, or
>
> 2) a manual change to each of Django's internal template tags - which
> would represent a lot of code churn to satisfy a use case that isn't
> entirely clear.
>
> Are you able to clarify how you would see this change happening in
> practice?
>
Well, it looks like the initialization of any templatetag by Django takes
place in a single point (Django 1.5 here):
self.enter_command(command, token)
try:
compile_func = self.tags[command]
except KeyError:
self.invalid_block_tag(token, command, parse_until)
try:
*compiled_result = compile_func(self, token)*
except TemplateSyntaxError as e:
if not self.compile_function_error(token, e):
raise
self.extend_nodelist(nodelist, compiled_result, token)
self.exit_command()
Maybe it would be sufficient to:
- modify class FilterExpression() to allow for a new syntax, i.e.
parameters which starts with "*" and "**",
- preparse token.contents to see, if variable parameters (varargs) were
passed,
- if no varargs were passed, take normal code path,
- else validate, that varargs are in right order/position with the respect
to the rest of arguments,
- wrap "compiled_result = compile_func(self, token)" call with some object
that defers underlying tag initialization to the render phase,
- in render phase call underlying tag initalization with varargs replaced
with values resolved from the current context.
Without actual implementation it is hard to say more. As usual, the devil
is in the detail (probably)
Regards,
Przemek Czerkas
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7d3a934b-58fa-4342-b5b2-4df8b3dfa024%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
