Hey Tom,
On Fri, 2007-07-13 at 23:19 -0500, Tom Tobin wrote:
> On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > A few comments (mostly questions) from an initial reading:
>
> I've now implemented most of your suggestions [1]; a few questions
> remain, though:
>
> 1) If I'm going to import the taghelpers errors/API into
> django.template, I'll need to in turn move the content in
> django.template.__init__ into a submodule (django.template.main,
> perhaps), or I run into circular import madness.
I don't see that as a problem. Currently, normal usage is "from django
import template", so moving things around under the template/ directory
should be fine so long as __all__ in __init__.py remains up to date.
> 2) I'm still not sure exactly how I should handle failed resolution if
> I simply resolve automatically; there are merits to each possible
> approach. a) Setting to None is more or less how Django currently
> does it, and doesn't provide any surprises. b) Setting to the string
> equivalent of the variable name is a useful trick, and what we do in
> several places internally by way of a "resolve_variable_or_literal"
> function; this in turn gave rise to the taghelpers "auto" resolution.
> Any suggestions here? (I suppose one solution would be to have a
> TagArg argument to choose between the two fallbacks.)
I'm not sure about this either. Maybe we need both behaviours (thinking
about "ifeqal" here). Looking at this again, I'm not sure what I was
hoping would happen, because the resolve parameter on TagArg is really a
tri-state, not a boolean. Probably I'm just on crack; let's leave it
alone.
> 3) Regarding Brian Harring's #3453, the type conversion logic is
> redundant between his approach and mine. taghelpers already avoids
> the issue he's trying to bypass, as it performs type conversion in one
> initial sweep and stores the literal values for later. I'd rather not
> use his approach in taghelpers; I don't like the idea of passing
> around LiteralVariables when I can be passing around
> honest-to-${deity} integers, strings, etc. :-)
Makes sense. Passing real Python objects feels more natural, you're
right.
>
> Ideally, I'd like to yank the type conversion logic out of
> resolve_variable, as I believe type conversion and variable resolution
> are really two separate things and should be available separately as
> needed.
Sounds reasonable.
> I'm fine with a utility function that does both; I just want
> the logic available separately. Right now, the type conversion logic
> in resolve_variable is needlessly called from taghelpers since type
> conversion has already occurred.
>
> Ultimately, Brian's approach may be fine as an available default; I
> just want that resolution logic available separately for taghelpers,
> dammit. ^_^
We don't need more than one way to do the same thing. I'd vote for
diving in and being a little more intrusive with this patch and just
reorganising things so that it's more efficient. I'll hold off on
committing that patch until we've worked through your changes to
conclusion.
Backwards compatibility is a good goal, though. So far, all you changes
have been fully compatible with existing code. If you're going to tweak
resolve_variable at all, there should still be a function called
resolve_variable() that works exactly as the current one does. That way,
people won't have to change their code. It should be possible, though, I
would think (without being too painful).
I'm having a "Django weekend" today and tomorrow. I'll read through the
patch again and see if I can resolve my last concerns. The two areas
I've been turning over in my head are
(1) whether the inner Meta class is really necessary. Currently it takes
one line of code to register a tag; you've replaced that with three
lines. Not sure if that's helpful or not.
(2) what sub-classing is going to work like. I haven't looked at this
yet, but I want to check that subclassing an existing tag to add
functionality is possible and not overly painful. With all the
meta-programming you're doing, it's not obvious to me (yet).
I'll have something by tomorrow.
Regards,
Malcolm
--
The hardness of butter is directly proportional to the softness of the
bread.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
