Am 25.11.2008 um 17:28 schrieb Jacob Kaplan-Moss:
> I'm actually pretty happy with the general idea you've taken here --
> django.template needs some cleanup, and a holistic approach that
> addresses the multiple issues at once is going to produce better code
> than multiple patches all stacked up.
>
> It seems most of the core team agrees -- it got 7 +0 votes. I think
> the only reason it failed to get any +1s is that it's just a big
> amount of work to review all at once. There's also the obvious
> question of weather we can pull off this refactoring without breaking
> backwards-compatibility.
I'm glad you like it, more on backwards-compatibility below.
> I think the best thing to do with this is to take it to a branch so we
> can easily evaluate it against the trunk templates. If you're down for
> working on this off on a branch, I'm willing to help out and also
> review your code.
>
>> * The code shuffling is purely cosmetic, it just feels wrong to stuff
>> everthing in __init__.py. It's already too big for my taste. And I
>> honestly don't know how to cleanly split shuffling and functionality
>> in separate patches.
>
> Yeah, this is the big reason a branch would be better -- we can
> separate the big deck-chair-shuffling from the refactoring and be able
> to review better.
>
>> * I always felt the API for custom tags is too verbose.
>
> There's almost universal agreement on this point :)
>
> It's unfortunately pretty tricky to do in a backwards-compatible way:
> we've sorta pasted ourselves into a corner here by letting tags do
> anything they want in terms of parsing. This lead to an inconsistency
> in syntax that we (unfortunately) have to continue to support.
>
> However, that's no reason not to have a better API on top that
> third-party tags can use -- as long as internal tags don't break.
That should be entirely possible, using either an additional decorator
for parser functions [EMAIL PROTECTED] or [EMAIL PROTECTED]($new_api=True)`, or
a new method [EMAIL PROTECTED] (for some reasonable value of
$new_api).
It might even be possible to fold `TokenStream` into `Token`, but that
would introduce state in `Token` - haven't thought this through.
The refactored version of defaulttags currently passes most tests with
the following exceptions
* {% if not not %} raises TemplateSyntaxError (fixable, but I'm not
shure it's worth it)
* integer literals with a trailing colon raise TemplateSyntaxError
* whitespace is insignificant, therefore {{ foo | filter }} passes.
The only real bc problem were unquoted unicode viewnames in {% url %}.
That's fixed in my latest patch at the expense of regexp beauty.
The current version accepts a quoted string as well, so one could
deprecate unquoted viewnames and fix that in 2.x.
That's been rejected in
http://groups.google.com/group/django-developers/browse_thread/thread/fd30cb20f80c6c79
.
> So: what do you say we make a template-cleanup branch and start
> working on this over there?
If it has to be a branch, so be it. I entered myself as implementor
into the feature table.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
