Re: Model.objects.raw() (#11863)
> So my question, and this is something I've been thinking about a lot > of the proposals lately is: why should this be in Django itself. I couldn't agree with your sentiment more, in the whole. In fact, to me, until now all of the proposals aside from Simon's seem better outside of Django than inside of it. That being said, this proposal is actually something that I think fits well within Django core itself, as it really is a logical extension of the core functionality of the ORM. Thanks, Eric Florenzano --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-firebird backend
On Mon, Sep 28, 2009 at 6:26 PM, maxi wrote: > > Hi, > I'm working on implementation of firebird backend for django [1] > I've an issue related of icontains filter option. Firebird uses > CONTAINING sql clause for this, which is case insesitive. > > The problem is that the output generated (where clause) is wrong. > It return: > > WHERE "TABLE"."FIELD" CONTAINING %value% > > And, the correct form should be: > > WHERE "TABLE"."FIELD" CONTAINING ' value ' > > It is using % instead ' > > The question is, which method I have to touch to change this > behavior? Take a look at the [1][2]'operators' attribute of the backend's DatabaseWrapper class and the [3]lookup_cast() method of the 'ops' attribute (usually an instance of a backend-provided subclass of DatabaseOperations). Both are [4]used for building that kind of queries. HTH, -- Ramiro Morales | http://rmorales.net 1. http://code.djangoproject.com/browser/django/trunk/django/db/backends/dummy/base.py?rev=11596#L39 2. http://code.djangoproject.com/browser/django/trunk/django/db/backends/sqlite3/base.py?rev=11596#L129 3. http://code.djangoproject.com/browser/django/trunk/django/db/backends/__init__.py?rev=11596#L229 4. http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/where.py?rev=11596#L166 --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
On Tue, Sep 29, 2009 at 9:29 AM, Alex Gaynor wrote: > > On Mon, Sep 28, 2009 at 9:24 PM, SeanOC wrote: >> >> Hello All, >> >> During the Djangocon sprints I started to work on a patch which would >> add a nicer interface for dealing with raw SQL queries. While there I >> talked to RKM about where it should fit into the ORM API and where in >> the code base should live. I've finally gotten around to finishing >> the code I wrote during the sprint and have posted a patch to the >> related ticket (http://code.djangoproject.com/ticket/11863). You can >> also get the code from http://github.com/SeanOC/django. >> >> So far the patch is functional and has some basic unit tests but it is >> not documented. I'll be working on the documentation this week. In >> the mean time, the unit tests are probably the best place too look for >> how to use the code. >> >> If anybody would like to look over the code and provide some feedback >> it would be greatly appreciated. >> >> Thanks! >> >> -SeanOC >> > >> > > So my question, and this is something I've been thinking about a lot > of the proposals lately is: why should this be in Django itself. This > looks to me like something that would work perfectly well outside of > Django itself, indeed it's just a custom manager. Yes, this *could* be done entirely externally. However, I think it is a manifestation of a pattern that we actively encourage, so therefore we should provide nice API support for it. I've lost count of the number of times I've said "ORM != SQL, so just use a cursor and write raw SQL". However, "write raw SQL" isn't always trivial, since you don't get back ORM objects. If you want ORM objects, you have to: (1) know about the trick of instantiating an object with the unrolled list version of a cursor, and (2) ensure that you've got all your columns specified in the right order. We can fix (1) with some documentation, but (2) is one of those nasty implementation details that you don't know you've got right until everything blows up in your face. There's also an edge case where two versions of a table might end up with different column orders due to applying different migration strategies on each version. If this happens, then the cursor approach fails because there is no consistent column order. If we can provide API-level support to make it easier to write custom SQL, I think we should do so. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.template refactoring (again) #7806
On Tue, Sep 29, 2009 at 12:44 AM, Johannes Dollinger
wrote:
>
>>> Variable and FilterExpression will be deprecated as they require the
>>> caller to know the length of the expression in advance.
>>
>> I'm not sure I follow this assertion. I have no problem believing
>> FilterExpression can be made cleaner, but Variable takes an expression
>> like 'article.section', plus a context, and resolves it into a string.
>> In itself, it seems like a well built and stable piece of API.
>
> To get this expression string in the first place you have to split
> Token.contents somehow. smart_split() does that well for space
> delimited expressions.
> But if you try to parse something like {% url %} you have to split its
> results again: "foo.bar,baz|filter:arg,42" won't do it. The current {%
> url %} parser now resorts to `str.split(",")` and
> {% url viewname list|join:"," %}
> will break it. Of course that's a corner case and could be fixed with
> something like `smart_split(delim=",")`. But it would be much more
> elegant if you could just read an expression from a stream of tokens.
> That's what I meant when I said "the {% url %} parser is broken by
> design". I didn't mean to sound harsh - {% url %}'s parser is a
> reasonable tradeoff between simplicity and correctness.
Sure - that explains why FilterExpression is a problem, but I don't
see why Variable is affected. Once you've parsed your expression into
tokens, those tokens that are known to be variables need to convert
'foo.bar' into something derived from context.
>>> 1.) Currently `Variable("unresolvable")` and
>>> `FilterExpression("unresolvable", p)` resolve differently: Variable
>>> raises VariableDoesNotExist and FilterExpression returns
>>> TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
>>> given. But `FilterExpression("foo|cut:unresolvable", p)` will again
>>> raise VariableDoesNotExist - regardless of `ignore_failures=True`.
>>>
>>> My Expression implementation unifies these behaviours: If any part of
>>> an expression is unresolvable a LookupError will be raised.
>>> `ignore_failures` will be deprecated but there's a resolve_safe()
>>> method on the Expression base class that reads:
>>>
>>> def resolve_safe(self, context, default=None):
>>> try:
>>> return self.resolve(context)
>>> except LookupError:
>>> return default
>>>
>>> This would be a small backwards incompatible change. I have one
>>> failing test (exception02) because the ExtendsNode implementation
>>> depends on the current FilterExpression behaviour.
>>
>> It's either backwards compatible or it isn't. Backwards compatibility
>> is a requirement, not an optional extra.
>
> If FilterExpression is not part of the public API this is a non-issue.
> The problem was that unresolvable variables were treated differently
> from unresolvable filter arguments.
While FilterExpression isn't part of the public API, the effects of
using FilterExpression _are_ part of public API. If I have code that
currently fails silently because of a badly named variable, *that
behaviour cannot change*. The fact that FilterExpression raises (or
doesn't raise) an exception is irrelevant. How that expression is
surfaced to the end-user is _very_ relevant.
>> I don't want to sound dismissive of the work you're done here, but
>> your comments in this post haven't inspired me to go looking deeper.
>> You've been a little cavalier with the term "backwards incompatible"
>> on a couple of occasions, which is something that simply isn't
>> acceptable in something as prominent and well documented as Django's
>> template language.
>
> Criticism is welcome. If FilterExpression is not public API ,
> everything should be backwards compatible now. That was the goal from
> the beginning.
> The {% if not %} and Variable("2.") fixes are ugly but compact.
> All tests pass (with two minor corrections: {% foo | bar %} is now
> valid and FilterExpression internals have changed).
The changes to internals don't especially concern me. However, I'm
unconvinced that "foo | bar" is a desirable change. I can see how it
would make your life easier, but unfortunately, that isn't the
criteria here :-)
>> There are bugs in the template system. Many of these are caused by
>> inconsistent handling of parsing, especially of variables. If you can
>> point at something that you think is a bug (such as the handlng of
>> foo._attrib), then it's no longer covered by backwards compatibility.
>> However, you don't get that accommodation simply because something
>> doesn't fit into your nice new parsing scheme.
>>
>> Now, some of this might just be a misunderstanding on my part -
>> especially with regards to what is partially implemented, what you
>> intend to fix, and what you think can't (or shouldn't) be fixed.
>> You've spent a lot of time describing your new parsing API, but not a
>> lot of time describing why the new API is required. To that end, I'm
>> not entirely sure how much
django-firebird backend
Hi, I'm working on implementation of firebird backend for django [1] I've an issue related of icontains filter option. Firebird uses CONTAINING sql clause for this, which is case insesitive. The problem is that the output generated (where clause) is wrong. It return: WHERE "TABLE"."FIELD" CONTAINING %value% And, the correct form should be: WHERE "TABLE"."FIELD" CONTAINING ' value ' It is using % instead ' The question is, which method I have to touch to change this behavior? Thanks in advance. -- Maxi. [1] http://code.google.com/p/django-firebird/ --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
On Mon, Sep 28, 2009 at 9:24 PM, SeanOC wrote: > > Hello All, > > During the Djangocon sprints I started to work on a patch which would > add a nicer interface for dealing with raw SQL queries. While there I > talked to RKM about where it should fit into the ORM API and where in > the code base should live. I've finally gotten around to finishing > the code I wrote during the sprint and have posted a patch to the > related ticket (http://code.djangoproject.com/ticket/11863). You can > also get the code from http://github.com/SeanOC/django. > > So far the patch is functional and has some basic unit tests but it is > not documented. I'll be working on the documentation this week. In > the mean time, the unit tests are probably the best place too look for > how to use the code. > > If anybody would like to look over the code and provide some feedback > it would be greatly appreciated. > > Thanks! > > -SeanOC > > > So my question, and this is something I've been thinking about a lot of the proposals lately is: why should this be in Django itself. This looks to me like something that would work perfectly well outside of Django itself, indeed it's just a custom manager. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Model.objects.raw() (#11863)
Hello All, During the Djangocon sprints I started to work on a patch which would add a nicer interface for dealing with raw SQL queries. While there I talked to RKM about where it should fit into the ORM API and where in the code base should live. I've finally gotten around to finishing the code I wrote during the sprint and have posted a patch to the related ticket (http://code.djangoproject.com/ticket/11863). You can also get the code from http://github.com/SeanOC/django. So far the patch is functional and has some basic unit tests but it is not documented. I'll be working on the documentation this week. In the mean time, the unit tests are probably the best place too look for how to use the code. If anybody would like to look over the code and provide some feedback it would be greatly appreciated. Thanks! -SeanOC --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Revisiting #8245: admin.py errors under runserver cause app to disappear
Hi all, Today I filed #11957 [1], and because it is questioning an earlier bugfix, I was asked to bring up the issue for discussion here. Under the dev server, if an error occurs while importing an app's admin.py, the error will show up on the first request, and then disappear. On all subsequent requests (until the dev server is restarted), the admin will load normally, but without that app or its models. Even if the admin.py is fixed, the app will be missing until the server is manually restarted. I've observed the confusion this causes to beginners working through part 2 of the tutorial: they learn that under most conditions the development server does not require a restart, and when they hit this situation there is no clue that restarting the dev server is the necessary fix. This confusing behavior is a consequence of the fix chosen for #8245 [2] and applied in r9680 [3]. In order to avoid spurious AlreadyRegistered errors masking the real error in an admin.py, a global LOADING flag was introduced that causes admin.autodiscover() to bail out if an earlier run did not finish successfully. The unintended side effect is that once autodiscover() has encountered an error in an admin.py under the dev server, it will perpetually bail until the server is manually restarted (runserver auto-reloading does not help here, because an admin.py that has failed to import is not in sys.modules, so fixing the error in it doesn't trigger a restart). There was an alternative patch attached to #8245 by jarrow that instead rolls back all changes to the admin's model registry if an error is encountered during autodiscover (thus avoiding spurious AlreadyRegistered exceptions, but without the need for a global flag). If I roll back r9680 and apply jarrow's patch instead, both #8245 and the issue I describe above are solved. Can anyone shed light on why jarrow's patch was rejected for #8245 (no reasons are provided in the ticket)? Is there any reason not to switch to that approach now in order to get more predictable behavior from admin.py errors under runserver? Thanks, Carl [1] http://code.djangoproject.com/ticket/11957 [2] http://code.djangoproject.com/ticket/8245 [3] http://code.djangoproject.com/changeset/9680 --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Sep 28, 6:57 pm, Rob Hudson wrote:
> For lack of knowing about anything better, I keep falling back to
> Werkzeug's HTMLBuilder class[1]. Pulled out and stripped of comments,
> it weighs in at 77 lines of code...
That's not so bad. I was worried about pulling in a large dependency,
but 77 lines (probably dropped in to django.utils.builder or similar)
isn't particularly alarming. I'm still a bit sceptical of introducing
another markup abstraction just to solve this one problem. I wonder if
it could be used to tackle the RSS/Atom generation problem as well?
> I agree with what I think I'm reading here -- a goal being to give
> designers more fine grained control over the form and form elements at
> the template level.
Yes, that's exactly it. Designers should be able to do anything they
like with forms at the template level (hence the {% field form.name
class="foo" %} suggestion). Again, this makes me slightly cautious
about the HTMLBuilder approach since exposing that at the template
level is virtually impossible.
> I think you might want both 1 and 3. (1) for those that want finer
> control or just don't want to use the underlying HTML wrapper, and (3)
> for those that do.
>
> Would it be something to consider adding special case tag, like
> comments, to represent the self closing slash depending on current
> context's doctype? For example, something like {% / %}?
I'm really not in favour of 3. 1 I think is OK - as I mentioned above,
I added it to django-html as {% slash %} and it's actually not that
unpleasant. I think I'd rather avoid adding custom syntax like {% / %}
just to support this one tiny edge case (I strongly expect most Django
developers won't ever want to write code that's doctype agnostic - and
as Max mentioned, HTML5 grandfathers in the /> syntax - the tag will
be used strictly by perfectionists).
Cheers,
Simon
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Mon, Sep 28, 2009 at 6:38 AM, Russell Keith-Magee wrote: > By way of greasing the wheels towards trunk: if the outcome of this > mailing list thread was a wiki page that digested all the ideas, > concerns and issues into a single page, it will make the final > approval process much easier. Luke Plant's wiki page on the proposed > CSRF changes [1] is a good model to follow here - I wasn't involved in > the early stages of that discussion, but thanks to that wiki page, I > was able to come up to speed very quickly and see why certain ideas > were rejected. > > [1] http://code.djangoproject.com/wiki/CsrfProtection I don't mind trying to piece a Wiki page together documenting the current conversation. I agree it will make a good pointer for reference and future discussions. -Rob --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Sep 26, 7:33 pm, Simon Willison wrote:
> 1. a {% selfclose %} template tag:
>
>
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
I've added an experimental {% slash %} tag to django-html to address
the reusable XHTML/HTML templates problem. It's actually not as
horrible as I first thought - you end up writing template code like
this:
It's not exactly beautiful, but it's the simplest thing that could
possibly work. Most Django developers who aren't writing code designed
to be used with differing doctypes won't ever have to use it. In the
absence of a better idea I'm pretty happy with it.
http://github.com/simonw/django-html
Cheers,
Simon
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Sep 28, 5:20 pm, Max Battcher wrote:
> I really don't see what the fuss here is about. If we are worried about
> forwards-compatibility, HTML 5 takes care of it. If we are worried about
> better backwards-compatibility with HTML 4, everyone else is saying that
> the future is now and the focus should be HTML 5...
>
> What is this argument really about?
http://www.djangoproject.com/ calls Django the web framework for
"perfectionists with deadlines". This is a perfectionist issue.
If the problem was incredibly hard to solve or involved breaking
backwards compatibility I'd drop this, but I don't think it's a
particularly big or difficult change. The django-html approach even
gives us a useful extra feature - it allows template developers to add
new attributes to form widgets without needing changes made to the
underlying Python form definitions:
{% field form.name class="foo" onfocus="bar()" %}
It's not just me that gets annoyed by this - when I'm teaching Django
to client-side engineers this tends to come up a lot - and I find the
answer a bit embarrassing. It's basically the only place in Django
that the template author can't control the markup, and good client-
side engineers are pretty picky.
Cheers,
Simon
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve some kind of light-weight helper for
> outputting tags though - render_tag('input', {'type': 'text', 'name':
> 'blah'}, xhtml=True) maybe.
For lack of knowing about anything better, I keep falling back to
Werkzeug's HTMLBuilder class[1]. Pulled out and stripped of comments,
it weighs in at 77 lines of code...
Here's a brief Python shell of how it works...
>>> html = HTMLBuilder('html')
>>> html.input(type='text', name='blah', value='"Quote & Ampersand"')
u''
>>> html.select(name='template', id='id_template', *[html.option(v, value=k)
>>> for k, v in dict({1: 'One', 2: 'Two', 3: 'Three'}).iteritems()])
u'OneTwoThree'
I really like how it handles children nicely, as in the select/option
example above.
>>> xhtml = HTMLBuilder('xhtml') # XHTML dialect
>>> xhtml.input(type='text', name='blah', value='"Quote & Ampersand"')
u''
This automatic CDATA escaping in XHTML is also nice:
>>> html.script('var id=document.getElementById("id")')
u'var id=document.getElementById("id")'
>>> xhtml.script('var id=document.getElementById("id")')
u'/**/'
I could see using something like this and making a template tag
wrapper around it like the namespace template tag you mention below.
I *think* that would simplify a lot of what you see in the Django
template widget render code that deals with attributes (e.g.
buildattrs, flattatt), which should make writing widgets and
sublcassing widgets a bit easier.
> The form.as_p stuff works as either HTML or XHTML. It would be nice to
> further emphasise the ease with which people can create their own
> reusable form templates (define them as an includable fragment that
> iterates over the form), and it would be nice if there were more
> finely grained methods for things like accessing the HTML ID of a form
> field. I don't see any reason to templatise those parts in particular
> though - unless someone has smart ideas about how baked in default
> templates could dramatically improve the overall form experience.
I agree with what I think I'm reading here -- a goal being to give
designers more fine grained control over the form and form elements at
the template level.
> That's tricky. There are really only a few tags that actually differ -
> anything that needs to be self closing, which means the following:
>
>
>
>
>
>
>
>
>
>
Also:
> Of these, only meta, link, img, input and br are really common. I can
> think of a few ways of dealing with this, none of them particularly
> enticing:
>
> 1. a {% selfclose %} template tag:
>
>
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
>
> 2. a {% tag %} tag:
>
> {% tag br %}
>
> Like the {% field %} tag, this could take optional attributes:
>
> {% tag br class="break" %}
>
> 3. {% field %} style tags for all of the self-closing XHTML tags:
>
> {% br %} {% br class="break" %}
> {% hr %}
> {% meta name="dc:author" value="Simon" %}
>
> This option really sucks - that's 9 new template tags polluting our
> default template namespace which do almost nothing. That said, if we
> added template tag namespacing we could at least do {% tag.br %}, {%
> tag.hr %} etc.
>
> They're all pretty horrible, but I think out of those I prefer option
> 1 (maybe with a better, shorter name).
I think you might want both 1 and 3. (1) for those that want finer
control or just don't want to use the underlying HTML wrapper, and (3)
for those that do.
Would it be something to consider adding special case tag, like
comments, to represent the self closing slash depending on current
context's doctype? For example, something like {% / %}?
[1] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126
I feel like I'm starting to get a picture in mind for all the pieces
at play here.
Thanks,
Rob
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: django.template refactoring (again) #7806
>> Variable and FilterExpression will be deprecated as they require the
>> caller to know the length of the expression in advance.
>
> I'm not sure I follow this assertion. I have no problem believing
> FilterExpression can be made cleaner, but Variable takes an expression
> like 'article.section', plus a context, and resolves it into a string.
> In itself, it seems like a well built and stable piece of API.
To get this expression string in the first place you have to split
Token.contents somehow. smart_split() does that well for space
delimited expressions.
But if you try to parse something like {% url %} you have to split its
results again: "foo.bar,baz|filter:arg,42" won't do it. The current {%
url %} parser now resorts to `str.split(",")` and
{% url viewname list|join:"," %}
will break it. Of course that's a corner case and could be fixed with
something like `smart_split(delim=",")`. But it would be much more
elegant if you could just read an expression from a stream of tokens.
That's what I meant when I said "the {% url %} parser is broken by
design". I didn't mean to sound harsh - {% url %}'s parser is a
reasonable tradeoff between simplicity and correctness.
> As best as I can make out, you are correct. FilterExpression appears
> to be an internal, so isn't covered by our backwards compatibility
> guarantees. However, Variable is documented API.
Variable and FilterExpression would still be around - compatible
versions live in `django.template.compat` - and import paths remain
functional.
>> 1.) Currently `Variable("unresolvable")` and
>> `FilterExpression("unresolvable", p)` resolve differently: Variable
>> raises VariableDoesNotExist and FilterExpression returns
>> TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
>> given. But `FilterExpression("foo|cut:unresolvable", p)` will again
>> raise VariableDoesNotExist - regardless of `ignore_failures=True`.
>>
>> My Expression implementation unifies these behaviours: If any part of
>> an expression is unresolvable a LookupError will be raised.
>> `ignore_failures` will be deprecated but there's a resolve_safe()
>> method on the Expression base class that reads:
>>
>> def resolve_safe(self, context, default=None):
>> try:
>> return self.resolve(context)
>> except LookupError:
>> return default
>>
>> This would be a small backwards incompatible change. I have one
>> failing test (exception02) because the ExtendsNode implementation
>> depends on the current FilterExpression behaviour.
>
> It's either backwards compatible or it isn't. Backwards compatibility
> is a requirement, not an optional extra.
If FilterExpression is not part of the public API this is a non-issue.
The problem was that unresolvable variables were treated differently
from unresolvable filter arguments.
>> 3.) Numeric literals ending with "." are currently treated as
>> Variables. The following test (ifequal-numeric07) succeds because
>> `ignore_failures=True` in IfEqualNode suppresses the inevitable
>> VariableDoesNotExist exception and then compares None to 2: ('{%
>> ifequal x 2. %}yes{% endifequal %}', {'x': 2}, ''). My current
>> implementation raises a TemplateSyntaxError as soon as it
>> encounters a
>> numeric literal with a trailing dot. This could easily be made
>> backwards compatible if it's considered worth it.
>
> Sorry, but this one can't change. "2." is a tested format for handling
> floats; the fact that this is inconvenient to your parser is
> irrelevant.
The problem is probably in bug in Variable:
>>> from django.template import Variable, Context
>>> Variable("2.").resolve(Context())
Traceback (most recent call last):
...
raise VariableDoesNotExist("Failed lookup for key [%s] in %r", (bit,
current)) # missing attribute
>>> Variable("2.").resolve(Context({"2": {"": "foo"}}))
'foo'
I originally wanted to parse "2." as a numeric literal. But there's
currently code that explicitly attempts to reject such literals:
http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py#L663
And here's how I fixed it in my branch (as mentioned in my second post
in this thread):
http://github.com/emulbreh/django/commit/73bc93b4dbf251968e062825439033de33597b08
>> * {% url ... %}, {% ssi ... %} currently accept unquoted literal
>> strings. This will continue to work but the preferred syntax will use
>> properly quoted strings. This may one day allow for viewnames and ssi
>> paths that come from expressions.
>
> At this point, this sort of fix can't happen until v2.0. It's would be
> a major change at this point. It's nice to know that the template
> parsing tools will handle it when the time comes, but I would expect
> that to be true of _any_ rework of the parser.
The proposed change is fully backwards-compatible. Both tags only gain
a new syntax variant. By documenting the unquoted variant as
deprecated means that newly written templates will alr
Re: Proposal: Better HTML4 support
Simon Willison wrote: > On Sep 26, 10:17 am, Max Battcher wrote: >> Furthermore, support for XHTML "5" (which is indeed a part of the HTML 5 >> standard) shows that XHTML 1's principles are still around and still >> respected. Django's XHTML output can't be "out of date" if XHTML 5 is >> considered a successor to XHTML 1. > > Opinions differ, but in the interest of keeping this thread about HTML > support in Django I'm going to leave that discussion here - let's > assume that it would be a Good Thing for Django should provide support > for outputting both HTML and XHTML, and focus on how we can achieve > that. But I'm not sure that is a correct assertion. I don't think there is a strong enough difference between HTML and the XHTML that Django generates for there to be a need for more complicated mechanisms of rendering. If the only point of contention is self-closing tags (), then HTML 4 might not support it explicitly (although in fact most modern browsers support it implicitly), but HTML 5 (the HTML form factor, not just XHTML 5) explicitly supports self-closing tags: http://dev.w3.org/html5/spec/Overview.html#start-tags Under Section 9.1.2.1 -- Start Tags, I quote: 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS (/) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. I really don't see what the fuss here is about. If we are worried about forwards-compatibility, HTML 5 takes care of it. If we are worried about better backwards-compatibility with HTML 4, everyone else is saying that the future is now and the focus should be HTML 5... What is this argument really about? -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.template refactoring (again) #7806
On Fri, Aug 28, 2009 at 9:41 PM, Johannes Dollinger
wrote:
>
> The proposal and motivation are essentially the same as in the last
> thread [1] and the ticket description [2]. I put it on the 1.2 feature
> list.
> I tried to split my patch into smaller, more readable commits here:
> http://github.com/emulbreh/django/tree/master
> I haven't converted defaulttags, loadertags and django.templatetags.*
> yet to show that it's (mostly) backwards compatible (see below). It
> would be useful to decide on some questions in the "API Design .."
> section below first.
>
> I'll summarize the core ideas again as well as problems and pending
> design decisions.
>
> Concepts: Expressions and TokenStream
> =
> Variable and FilterExpression will be deprecated as they require the
> caller to know the length of the expression in advance.
I'm not sure I follow this assertion. I have no problem believing
FilterExpression can be made cleaner, but Variable takes an expression
like 'article.section', plus a context, and resolves it into a string.
In itself, it seems like a well built and stable piece of API.
> This makes
> whitespace handling cumbersome and some syntactical constructs really
> hard to parse (e.g., the {% url ... %} parser is broken by design).
Saying {% url %} is "broken by design" doesn't accurately represent
the problem - it was a victim of inadequate tag building tools, and
now can't be fixed due to backwards-compatibility guarantees.
> Variable vs FilterExpression
> ==
> I could only find documentation for Variable. If the internally used
> Parser.compile_filter() is indeed undocumented there is no official
> way to use FilterExpression in custom tags. If that means that
> FilterExpression.resolve() behaviour doesn't have to be backwards
> compatible, that would help a lot ..
As best as I can make out, you are correct. FilterExpression appears
to be an internal, so isn't covered by our backwards compatibility
guarantees. However, Variable is documented API.
> 1.) Currently `Variable("unresolvable")` and
> `FilterExpression("unresolvable", p)` resolve differently: Variable
> raises VariableDoesNotExist and FilterExpression returns
> TEMPLATE_STRING_IF_INVALID. Except when `ignore_failures=True` is
> given. But `FilterExpression("foo|cut:unresolvable", p)` will again
> raise VariableDoesNotExist - regardless of `ignore_failures=True`.
>
> My Expression implementation unifies these behaviours: If any part of
> an expression is unresolvable a LookupError will be raised.
> `ignore_failures` will be deprecated but there's a resolve_safe()
> method on the Expression base class that reads:
>
> def resolve_safe(self, context, default=None):
> try:
> return self.resolve(context)
> except LookupError:
> return default
>
> This would be a small backwards incompatible change. I have one
> failing test (exception02) because the ExtendsNode implementation
> depends on the current FilterExpression behaviour.
It's either backwards compatible or it isn't. Backwards compatibility
is a requirement, not an optional extra.
> 2.) Currently `Variable("a._hidden")` works - but
> `FilterExpression("a._hidden", p)` raises a TemplateSyntaxError. This
> would be unified: lookup parts may not start with an underscore. If
> it's not acceptable to break bc here leading underscores might simply
> be allowed.
I'm inclined to say this is a bug with FilterExpression. Underscored
variables shouldn't ever be exposed.
> 3.) Numeric literals ending with "." are currently treated as
> Variables. The following test (ifequal-numeric07) succeds because
> `ignore_failures=True` in IfEqualNode suppresses the inevitable
> VariableDoesNotExist exception and then compares None to 2: ('{%
> ifequal x 2. %}yes{% endifequal %}', {'x': 2}, ''). My current
> implementation raises a TemplateSyntaxError as soon as it encounters a
> numeric literal with a trailing dot. This could easily be made
> backwards compatible if it's considered worth it.
Sorry, but this one can't change. "2." is a tested format for handling
floats; the fact that this is inconvenient to your parser is
irrelevant.
> Tags
> =
> * {% url ... %}, {% ssi ... %} currently accept unquoted literal
> strings. This will continue to work but the preferred syntax will use
> properly quoted strings. This may one day allow for viewnames and ssi
> paths that come from expressions.
At this point, this sort of fix can't happen until v2.0. It's would be
a major change at this point. It's nice to know that the template
parsing tools will handle it when the time comes, but I would expect
that to be true of _any_ rework of the parser.
> * {% if not %} would fail with my current implementation. This is
> fixable. But I'm not sure it's worth it: not/and/or should be keywords
> in the context of boolean expressions.
I'm unclear what you're proposing here. {% if not %} is a well
documented API, so i
Re: Proposal: Better HTML4 support
On Sun, Sep 27, 2009 at 1:34 AM, Rob Hudson wrote: > > On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison > wrote: >> Yes - I looked briefly at how much work was involved in doing this and >> it's not insubstantial, which is why I opted for string replacement >> just to demonstrate the API. I'm confident the exact functionality of >> django-html could be replicated in a less messy way by patching core, >> but it would require quite a bit of refactoring of django.forms. > > This is the bit I was hoping we could get to. What would that > refactoring look like, you think? Would it involve making forms use > Templates? Or something else? This is idea that I think has a lot of merit. Django has always had a policy of being client-side agnostic - the XHTML-specific output format has always been the chink in that armor. The impending significance of HTML5 increases the incentive to have this debate (and more importantly, to get it right). If this requires changes to the way forms and fields are rendered, I'm happy to entertain those ideas, as long as they retain backwards compatibility. However, as with the signed cookie discussion, I don't have any particularly strong opinions on the exact form that the API should take, so I will stay out of the discussion and let the community evolve the idea. By way of greasing the wheels towards trunk: if the outcome of this mailing list thread was a wiki page that digested all the ideas, concerns and issues into a single page, it will make the final approval process much easier. Luke Plant's wiki page on the proposed CSRF changes [1] is a good model to follow here - I wasn't involved in the early stages of that discussion, but thanks to that wiki page, I was able to come up to speed very quickly and see why certain ideas were rejected. [1] http://code.djangoproject.com/wiki/CsrfProtection Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
request.get_host() fails when behind multiple proxies (bug #11877)
Hi I was hoping someone could take a look at this bug at some point, and make a decision about the best course of action to take. http://code.djangoproject.com/ticket/11877 Cheers Tom --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
FastCGI + Lighttpd documentation
Hi, is there a particular reason why Lighttpd documentation advices user to create a separate script (for example, an init script) to create the socket with manage.py? Why not let the Lighttpd take care of spawning processes as needed? If no-one is against it, I could file a ticket about this and write the new documentation - Jyrki --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
This is unrelated Andreas. HTML5 has the exact same syntax as HTML4,
just new tags.
This thread is about syntax.
By the way, neither html4 nor xhtml are deprecated. HTML5 is still not
"officially released".
J. Leclanche / Adys
On Mon, Sep 28, 2009 at 12:12 PM, Andreas wrote:
>
> html4 is derecated.
> xhtml is deprecated.
>
>
> With google chrome frame out there theres absolutly no reason to not
> begin with html5 already.
> The longer we wait, the longer it will take before html5 becomes "the
> it".
>
>
>
> On Sep 27, 1:46 pm, Simon Willison wrote:
>> On Sep 27, 10:49 am, veena wrote:
>>
>> > my bits to discussion about supporting various (X)HTML versions.
>>
>> > 1) Problem with (X)HTML in python code (in applications)
>> > I discovered this python packagehttp://pypi.python.org/pypi/html/1.6
>> > It allows you to write "python like HTML syntax" and generates HTML or
>> > XHTML.
>>
>> Something like that might be an option for cleaning up the way markup
>> is generated within the forms framework itself, but ultimately I think
>> adding an entirely new Python-based generation method just to output a
>> few strings wouldn't be worth the added dependency.
>>
>> > 2) Problem with (X)HTML in templates
>> > I think there should be parser, which parse template just before
>> > caching templates. Code could be messy HTML or (XHTML) or invalid HTML
>> > (like undisclosed tags, attributes without quotations marks etc.) and
>> > from this make pretty HTML or XHTML according to html coder settings
>> > by {% doctype %}
>>
>> The performance overhead rules out this kind of approach for Django
>> core - any post-processing run against the output of the templates
>> would be executed on every single Django request, and HTML parsing and
>> rewriting is a very expensive operation. That's not to say a third
>> party module couldn't be written to do this kind of thing for people
>> who really want to clean up their output (I remember there being an
>> HTMLTidy middleware a few years back that did this) but it wouldn't be
>> suitable for inclusion in core.
>>
>> Cheers,
>>
>> Simon
> >
>
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
html4 is derecated.
xhtml is deprecated.
With google chrome frame out there theres absolutly no reason to not
begin with html5 already.
The longer we wait, the longer it will take before html5 becomes "the
it".
On Sep 27, 1:46 pm, Simon Willison wrote:
> On Sep 27, 10:49 am, veena wrote:
>
> > my bits to discussion about supporting various (X)HTML versions.
>
> > 1) Problem with (X)HTML in python code (in applications)
> > I discovered this python packagehttp://pypi.python.org/pypi/html/1.6
> > It allows you to write "python like HTML syntax" and generates HTML or
> > XHTML.
>
> Something like that might be an option for cleaning up the way markup
> is generated within the forms framework itself, but ultimately I think
> adding an entirely new Python-based generation method just to output a
> few strings wouldn't be worth the added dependency.
>
> > 2) Problem with (X)HTML in templates
> > I think there should be parser, which parse template just before
> > caching templates. Code could be messy HTML or (XHTML) or invalid HTML
> > (like undisclosed tags, attributes without quotations marks etc.) and
> > from this make pretty HTML or XHTML according to html coder settings
> > by {% doctype %}
>
> The performance overhead rules out this kind of approach for Django
> core - any post-processing run against the output of the templates
> would be executed on every single Django request, and HTML parsing and
> rewriting is a very expensive operation. That's not to say a third
> party module couldn't be written to do this kind of thing for people
> who really want to clean up their output (I remember there being an
> HTMLTidy middleware a few years back that did this) but it wouldn't be
> suitable for inclusion in core.
>
> Cheers,
>
> Simon
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
