Re: Proposal: Better HTML4 support
On Sep 26, 6:50 am, Jerome Leclanche wrote:
> This is a non-issue.
Obviously I disagree - this is a tiny thing that has bugged me ever
since newforms. It's also something I find myself constantly
apologising to front-end developers about, who for the most part love
the Django template language.
After 9 years In the marketplace, I think XHTML has pretty much lost.
It turns out that XML serialisations of HTML aren't nearly as useful
as people thought they would be (running an XML parser against the web
won't get you anywhere fast, and there are plenty of excellent HTML
parsing libraries now), and strict XML error handling is completely
unsuitable for the practical considerations of the web. HTML 5 is the
final nail in the coffin - the refocusing of the W3C on that over
XHTML 2 is an acknowledgement that XML is no longer the future of the
Web. I actually think Django's XHTML output makes us look a bit out of
date.
> Correct me if I'm wrong, but is valid html syntax. It's parsed
> as valid by every html parser, and I'm positive this is the entire
> point of xhtml: staying backwards-compatible with html.
If you want backwards compatibility you need HTML 5, not XHTML.
HTML 5 is backwards compatible - it even goes as far as specifying the
error handling routines that browsers should take when faced with
invalid code (routines that have been reverse-engineered from existing
browsers) and properly specifying all of the APIs that browsers
support but were never actually part of a specification, such as
XMLHttpRequest and innerHTML.
XHTML 1.0 is kind-of backwards compatible, but it's a bit of a fudge.
It's really meant as a transitional stage between HTML 4 and the
stricter XHTML 1.1. As an example of a fudge, the self-closing
tags actually mean something different in SGML (HTML's parent
language) - they're a short-hand feature called Null End Tags which
should technically result in extra > signs appearing in the text, but
thankfully no browser actually supports enough of SGML for that to be
a problem.
The moment you start serving XHTML with the correct content-type
(application/xml+html) all sorts of nasty things happen - in addition
to strict error handling the way the JavaScript DOM works
fundamentally changes - document.getElementsByTagName becomes
getElementsByTagNameNS for example.
XHTML 1.1 backwards incompatible - the spec forbids the use of the
text/html content-type and insists on application/xhtml+xml or
application/xml, which breaks completely in IE and causes other
browsers to use strict error handling (which you really, really don't
want).
XHTML 2.0 was completely backwards incompatible (tags were removed,
new incompatible tags added), a major factor in the W3C ending
official work on it.
> That said, I'm not against a {% doctype %} tag or anything. However, I
> do think having an xhtml default is a Good Thing due to its backwards
> compatibility.
I see XHTML as a dead end, so I'd personally prefer to switch to an
HTML 5 default - but the {% doctype %} thing makes switching to HTML 5
painless enough that I wouldn't mind the existing XHTML behaviour
remaining as the default (purely to avoid causing issues with existing
applications).
> I'm also not entirely fond of the idea of having 100
> different language outputs in Django. Why stop only after xhtml and
> html?
Because Django is a Web framework, and XHTML and HTML are the key web
languages. I don't think we need to worry about support for those two
leading to a slippery slope.
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
Simon Willison wrote: > HTML 5 is the > final nail in the coffin - the refocusing of the W3C on that over > XHTML 2 is an acknowledgement that XML is no longer the future of the > Web. I actually think Django's XHTML output makes us look a bit out of > date. I don't think either of those conclusions can be drawn from the facts. XHTML 2 was a bold attempt to redefine what it is exactly that web pages produce: less crud, more content. I'm, personally, a bit disappointed that it has been "canceled", but I assume that smart people will continue to explore concepts in that direction. XHTML 2's cancellation does not say that XHTML 1 was a bad idea or is in anyway invalidated and it absolutely says nothing about XML. (Also, whether or not XML is the "future" of the web, it is a strong part of what defines the "present".) 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. -- --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: Proposal: Better HTML4 support
On Sep 26, 5:48 am, Rob Hudson wrote:
> First, let's not let this turn into an argument about HTML vs XHTML.
Oops, sorry!
> People have their preference one way or the other, and I believe
> Django should be agnostic.
Completely agree - that's why I'm in favour of a Django doctype switch
rather than a fullscale switch to HTML 5.
> django-html Shortcomings:
> * Fixes the symptom, not the bug. [1] I think the fix should not do
> string replacement, but output the correct HTML in the first place.
> (I realize this is the best one can hope for as a 3rd party app, but
> if something were to come into core it would have the ability to fix
> things properly.)
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.
> * Doesn't "fix" the rest of the areas where Django outputs XHTML. Is
> it possible?
I think the key problem is template filters, which often produce XHTML
(linebreaksbr for example). This could be solved by allowing template
filters selective access to the template context, which I'm in favour
of in the absence of a compelling argument against. This could be done
in a way that allows existing filters to continue to work - maybe
something as simple as this:
register.filter('cut', cut, takes_context=True)
Which emulates the register.inclusion_tag API.
> 2. Add a new setting, e.g. settings.DOCTYPE, that various parts of
> Django and 3rd party apps use to render HTML.
>
> Advantages:
> * Simple and straightforward
>
> Shortcomings:
> * Yet another setting
> * Doesn't allow for template level decisions of doctype by designers
Really not keen on that - designers should be able to pick their
doctype, and there are some cases where specific pages of a site (or
of a reusable app) might need to use a specific doctype - MathML
output still requires XHTML for example.
I've somewhat foolishly volunteered for a bunch of 1.2 related hacking
already (CSRF, logging, signing) but I remain actively interested in
this, so I'll try to keep an eye on things and see if there's anything
I can contribute.
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
-~--~~~~--~~--~--~---
Check Constraints for databases that support them
I'm very interested in the idea of expanding the database level
constraints that can be supplied to a database schema, and also
automatically apply the same constraints to the model/view in django.
The various backends that support them, I believe already apply such
constraints for PositiveIntegerField() and so on.
I would like to see the ability to define extra constraints as part of
the model definition, and have these applied in a similar manner to
the unique and unique_together constraints.
I am more familiar with PostgreSQL than anything else, but I believe
the syntax I am about to propose will work in several databases.
Check constraints can be divided into two types: column level and
table level. With PostgreSQL, a column level constraint can reference
another column, but I would suggest that a constraint that does so
should be a table level constraint.
Column level constraints could be declared as a keyword argument to
the field constructor:
column = models.IntegerField(constraint='< 100')
Table level constraints could be declared as an attribute on the Meta
class of the model:
check_constraints = ('start < finish', )
Validation of the models should pick up when an incorrect constraint
has been declared. For instance, not using a valid operator ('# 100')
or not supplying a valid comparison value ('< 1e' for an IntegerField)
would be invalid column constraints, and comparing a Date to an
Integer would be an invalid table level constraint.
The code that should be generated would add "CHECK ('column' < 100)"
to the column definition in the first instance, and "CONSTRAINT
app_table_start_finish CHECK ('start' < 'finish')" to the table
definition in the second case.
I have already written code that fulfils these requirements, and some
tests for validation errors. I have also written additions to
BaseModelForm which validates according to the defined constraint(s).
At this stage, I have not allowed for more complicated relationships,
such as ('first < second + 65'), but this is planned.
Is there anyone else interested in this? Should I put this into a
ticket and attach my current diff?
--~--~-~--~~~---~--~~
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
Pong. On Sat, Sep 26, 2009 at 2:36 AM, Johannes Dollinger wrote: > > Ping. Anyone? > > > > > --~--~-~--~~~---~--~~ 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: Url resolver issues
The regular expression was incorrect (sorry i was half drunk at the
time of doing it), it is:
url(r'^approved/(((?P[a-zA-Z ,-]+)/)?)(((?P
[0-9]+)/)?)$', views.get_approved_images, image_info,
name='approved'),
I think it is a much nicer solution to only require one url pattern
for use in the templates. However, as there seems to be no option to
resolve the URL i have no choice.
On Sep 25, 4:37 pm, Michael wrote:
> On Fri, Sep 25, 2009 at 11:22 AM, Lewis Taylor
> wrote:
>
>
>
>
>
> > I should have also noted all url resolves fail, not just with no
> > arguments.
>
> > On Sep 25, 4:11 pm, Lewis Taylor wrote:
> > > Here it goes:
>
> > > I wanted a clean url structure so i tried to abstract as much as i
> > > could in one url pattern. it looks something like this:
>
> > > url(r'^approved/((?P[a-zA-Z ,-]+)?)(/?)((?P[0-9]+)?)(/?)
> > > $', get_approved_images, name='approved_images')
>
> > > this in theory should allow the return of
> > > 1) all images - /approved/
> > > 2) pagination options for all images - /approved/2/
> > > 3) images from a specific country - /approved/china/
> > > 4) pagination for countries - /approved/china/3/
>
> > > this works fine, but when trying to resolve the url with no page or
> > > country there are problems i.e.
>
> > > {% url approved_images %}
>
> > > i thought as there can be 0 or 1 of both country and page as specified
> > > in the url pattern there shouldn't be a problem, however it doesn't
> > > seem that way. I haven't looked inside the code as i have higher
> > > priority things to do at present, but if anyone could help with a
> > > solution or a reason why it doesn't work that would be appreciated, if
> > > not i suggest a patch as it makes sense that allowing url's to match a
> > > particular pattern should also mean that any url that matches that
> > > pattern should be resolvable :-)
>
> This feels like a how to question to me, so it might be better to take this
> onto django-users.
>
> If you are proposing that the urlresolver should be able to reverse this, I
> won't weigh in on the technical problems that might exist and just ask you:
>
> Do you really think this is easier than setting up different url patterns
> for each of the different views? I know it means 3 more lines of code, but
> that regular expression is a beast, that can't be easy for readability.
>
> On top of this these urls will also resolve for you: /approved2/,
> /approvedchina3/, /approved. This means you have multiple urls for the same
> resource. A major no no for SEO and just for content in general. Also if the
> urlresolvers were to work, which way would they work?
>
> This really kills the explicitness of the code, as well as the readiblity;
> we all are not regex masters. I think 3 different urlpatterns is much
> better. You can still reuse the view and have different names and it will
> work as advertised.
>
> Just my thoughts,
>
> Michael
--~--~-~--~~~---~--~~
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: Check Constraints for databases that support them
On Sep 26, 10:27 pm, Tim Chase wrote:
> > Is there anyone else interested in this?
>
> yes, I'd be interested in seeing some sort of database-level
> CHECK constraint as part of Django. I had been sitting on my
> thoughts until I see the GSoC work done on model-validation wend
> its way towards trunk. My hope had been to see model validation
> incorporate some DB-level CHECK constraints where feasible.
I did have a brief look at the django-check-constraint project on
google code, but it was overkill for what I needed.
> One of the other difficulties involves database expression
> differences. For the simple cases such as you suggest, it's not
> as bad as they're fairly standard. However, when functions are
> involved, each DB seems to have its own family of functions.
> E.g. if you want to assert the length of a string is 10
> characters ("len" vs. "strlen"?) or the time is during business
> hours ("hour(fieldname) between 8 and 17"...extracting
> time-portions varies across DB engines).
Yeah, for the time being I was only interested in simple cases.
Comparing against a static value in the case of column constraints,
and comparing two columns in the table-level case. I don't even allow
for 'start < finish + 1' in the code I have written so far.
> I currently just add the CHECK constraints manually (well, in
> post-syncdb code). Having them in a declarative fashion would
> help keep them in the right place.
Not to mention that it will allow the same code to control the db-
level constraint, and the django validation (admin, form). Which is
DRY, and one of the reasons I am moving projects to django.
I also looked a little bit at south, which I have just started using
for migrations. It doesn't have anything in there that is that
useful, other than raw SQL. Which can do those type of things, but it
is nicer to move into the declaration.
Matt.
--~--~-~--~~~---~--~~
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, 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. 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: Check Constraints for databases that support them
> Is there anyone else interested in this?
yes, I'd be interested in seeing some sort of database-level
CHECK constraint as part of Django. I had been sitting on my
thoughts until I see the GSoC work done on model-validation wend
its way towards trunk. My hope had been to see model validation
incorporate some DB-level CHECK constraints where feasible.
One of the other difficulties involves database expression
differences. For the simple cases such as you suggest, it's not
as bad as they're fairly standard. However, when functions are
involved, each DB seems to have its own family of functions.
E.g. if you want to assert the length of a string is 10
characters ("len" vs. "strlen"?) or the time is during business
hours ("hour(fieldname) between 8 and 17"...extracting
time-portions varies across DB engines).
I currently just add the CHECK constraints manually (well, in
post-syncdb code). Having them in a declarative fashion would
help keep them in the right place.
-tim
--~--~-~--~~~---~--~~
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 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?
> I think the key problem is template filters, which often produce XHTML
> (linebreaksbr for example). This could be solved by allowing template
> filters selective access to the template context, which I'm in favour
> of in the absence of a compelling argument against. This could be done
> in a way that allows existing filters to continue to work - maybe
> something as simple as this:
>
> register.filter('cut', cut, takes_context=True)
>
> Which emulates the register.inclusion_tag API.
We've got django.forms and tags/filters on the plate. How might we
fix something like comments which has templates which write out XHTML
(or other little places which hand code HTML)?
For example, if one includes contrib.comments in their HTML4 website,
it doesn't validate...
http://validator.w3.org/check?uri=http%3A%2F%2Fjacobian.org%2Fwriting%2Fsnakes-on-the-web%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Ahem. Sorry Jacob!
I'd really hate to see something like this everywhere:
> Really not keen on that - designers should be able to pick their
> doctype, and there are some cases where specific pages of a site (or
> of a reusable app) might need to use a specific doctype - MathML
> output still requires XHTML for example.
I agree.
Simon mentioned how HTML and XHTML could result in Javascript and DOM
differences -- should we be concerned about being too dynamic about
swapping out HTML for XHTML, and vice versa, for fear of breaking
Javascript and CSS that rely on them?
For example, I think the Django admin is fine as XHTML since it isn't
intended to be an included part of your website. But say we were able
to easily set a different doctype that rendered as HTML4. Does that
have the possibility of really breaking things?
> I've somewhat foolishly volunteered for a bunch of 1.2 related hacking
> already (CSRF, logging, signing) but I remain actively interested in
> this, so I'll try to keep an eye on things and see if there's anything
> I can contribute.
If we can come up with something that everyone is happy with, I'm in
for volunteering time to help code it. I'm sure it will be a learning
experience for me as far as Django internals, but I'm willing to put
the effort into it.
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: Proposal: Better HTML4 support
Another fun wrinkle to think about in this discussion is third-party
apps. Currently there are numerous useful apps out there which you
can't really use if you want to have HTML(5) output because they have
XHTML output hard-coded. The developers of these apps haven't done a
"bad" thing here, they simply mirrored Django's own behavior.
As an interim solution I've forked django-html (http://github.com/
SeanOC/django-html) and added a middleware which does the XHTML=>HTML
string replacement. This is obviously a fairly messy approach but it
is the only way I've figured out to work with third party apps without
maintaining HTML compatible forks of everything.
To address this problem the "right" way, I'd suggest that in addition
to fixing Django's own HTML output to respect a {% doctype %} tag, we
should also provide tools to make it easy for developers to respect
that tag. I'm not sure what form those tools should take right now
but it's definitely something that should be consider as part of the
solution to this problem.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
CSRF - next step?
Hi all, I just want to know what the status is before committing the CSRF stuff: * Jacob am I waiting for a thumbs up? I think you said you were going to try out the code. * Simon am I waiting for your patch? If I'm not waiting for either, my plan would be: * Commit what I've got pretty much as is. * Then move it all from contrib to core * Question: where should the docs (currently ref/contrib/csrf.txt) be moved to? ref/csrf.txt seems like a sensible place, but I don't know. * Then add a render_to_response_with_request shortcut (once we can decide on a colour...) and adjust the tutorials. Simon: * I could wait for you to write your csrf_protect_form code before doing any of this, merge it and then do the above. * You could write it against my lp-csrf_rework branch (which is not going to change substantially), and I can move your patch over to core (or you could move it). * You could wait 'til I'm done so that we don't have to worry about the fact that everything is going to move. Personally, I think your patch would be better going in separately, as it is additional functionality that is not used by default anywhere. Also, I have written a Python script that attempts to help people find all the s and view code that needs attention. It has a whole bunch of limitations and caveats, but I think it's pretty useful 90% solution and automates a lot of what people would have done using grep etc. Where should it go? It's currently in 'extras/' which seems to be the right place. Luke -- "Smoking cures weight problems...eventually..." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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, 6:34 pm, Rob Hudson wrote:
> 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?
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.
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.
> We've got django.forms and tags/filters on the plate. How might we
> fix something like comments which has templates which write out XHTML
> (or other little places which hand code HTML)?
That's tricky. There are really only a few tags that actually differ -
anything that needs to be self closing, which means the following:
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).
> For example, I think the Django admin is fine as XHTML since it isn't
> intended to be an included part of your website. But say we were able
> to easily set a different doctype that rendered as HTML4. Does that
> have the possibility of really breaking things?
The JavaScript differences only come up when you start serving stuff
as application/xml+xhtml, which I would strongly suggest we avoid
doing at all costs (hence the need to stick the admin with XHTML 1.0
and avoid ever upgrading to 1.1). I'm not worried about that aspect.
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: CSRF - next step?
On Sat, Sep 26, 2009 at 2:29 PM, Luke Plant wrote: > > Hi all, > > I just want to know what the status is before committing the CSRF > stuff: > > * Jacob am I waiting for a thumbs up? I think you said you were going > to try out the code. > * Simon am I waiting for your patch? > > If I'm not waiting for either, my plan would be: > * Commit what I've got pretty much as is. > * Then move it all from contrib to core > * Question: where should the docs (currently ref/contrib/csrf.txt) > be moved to? ref/csrf.txt seems like a sensible place, but I > don't know. > * Then add a render_to_response_with_request shortcut (once we > can decide on a colour...) and adjust the tutorials. > So I'm still a little unclear on what this shortcut does that direct_to_template doesn't already? > Simon: > * I could wait for you to write your csrf_protect_form code before > doing any of this, merge it and then do the above. > * You could write it against my lp-csrf_rework branch (which is not > going to change substantially), and I can move your patch > over to core (or you could move it). > * You could wait 'til I'm done so that we don't have to worry about > the fact that everything is going to move. > > Personally, I think your patch would be better going in separately, as > it is additional functionality that is not used by default anywhere. > > Also, I have written a Python script that attempts to help people find > all the s and view code that needs attention. It has a whole > bunch of limitations and caveats, but I think it's pretty useful 90% > solution and automates a lot of what people would have done using grep > etc. Where should it go? It's currently in 'extras/' which seems to > be the right place. > > Luke > > -- > "Smoking cures weight problems...eventually..." (Steven Wright) > > Luke Plant || http://lukeplant.me.uk/ > > > > 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 -~--~~~~--~~--~--~---
Re: CSRF - next step?
On Saturday 26 September 2009 19:44:24 Alex Gaynor wrote: > So I'm still a little unclear on what this shortcut does that > direct_to_template doesn't already? It just has a slightly different and simpler API, and an import that does not involve generic views. It also *doesn't* do some things that direct_to_template *does* do, like the params dictionary. I think it needs to be simple and obvious enough to be used early in the tutorials, before generic views have even been introduced. But it's certainly an optional part of the CSRF stuff - just something to make using RequestContext easier and simpler. Luke -- "Smoking cures weight problems...eventually..." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: CSRF - next step?
On Sep 26, 7:44 pm, Alex Gaynor wrote:
> So I'm still a little unclear on what this shortcut does that
> direct_to_template doesn't already?
It's a bit less weird. direct_to_template lives somewhere I can't
remember (so I rarely import it), has an argument called
"extra_context" that's actually just the regular context, sets up a
surprising 'params' key in the context dictionary that contains the
function's **kwargs, executes any of the context arguments that are
callables before passing them to the template (even though the
template language usually does that anyway) and has an argument called
mimetype when as-of Django 1.0 content_type is the preferred name for
that parameter [1]. direct_to_template is also an odd name - it makes
sense for a generic view, but it feels strange when you're using it to
render a template from within your view code.
Personally, I want a shortcut called django.shortcuts.render which
looks like this:
def render(request, template, context=None,
content_type=DEFAULT_CONTENT_TYPE):
return render_to_response(template, context or {},
context_instance=RequestContext(request),
mimetype=content_type
)
Much less surprising than direct_to_template, and much easier to
import. I use this in basically every single one of my view functions
so I'd prefer a name that is concise over one that is more
descriptive. That's assuming I can't get any buy-in for my
TemplateResponse concept[2].
Cheers,
Simon
[1] (On further inspection it looks like my attempt to get mimetype
replaced by content_type throughout Django 1.0 was something of an
abject failure, since mimetype is used by both render_to_response and
direct_to_template)
[2] http://github.com/simonw/django-openid/blob/master/django_openid/response.py
- I really like the idea of custom HttpResponse classes that are
lazily evaluated just like QuerySets are, but I've got enough stuff to
evangelise for 1.2 already ;)
--~--~-~--~~~---~--~~
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: decorator_from_middleware change
If you search for `cache_page` decorator than it becomes clear that traditional approach is to use it in now unsupported way: myview = cache_page(myviewt, timeout) For example here: http://www.google.com/codesearch?hl=ru&sa=N&q=%22+%3D+cache_page%22++lang:python&ct=rr&cs_r=lang:python nobody uses `myview = cache_page(timeout, myview)` syntax. So I suppose this change can broke a lot of third-party apps, for example django-robots and django-mediafiles. > I don't know for certain how many people may be using this idiom, since it was never documented (AFAICT cache_page always documented itself as putting the timeout first and the view function second), so I'm not really sure what (if anything) we should do about it. Not true. cache_page decorator is now documented as putting view first and timeout second. Take a look at http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-cache Another thought. If key_prefix is deprecated in cache_page decorator maybe it should be also deprecated in CacheMiddleware? On 24 сен, 05:50, Luke Plant wrote: > On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote: > > > No, I think this is precisely correct. I've been meaning to do > > exactly what you're proposing for a while myself; just haven't > > gotten around to it. > > > > decorator_from_middleware isn't actually documented anywhere > > > I actually avoided documenting it because it's broken. Once you fix > > it, we should (i.e. I will, if you don't have time) document it. > > OK, it's committed now. (r11586, r11593) > > Technically this is a bug fix (#6371), so it ought to get backported > to 1.1.X. However, it does actually introduce backwards > incompatibilities with cache_page (cache_page still works exactly as > documented, but various people were using various undocumented > features of it). Also, you could argue it is a new feature - "these > decorators now work with methods". > > So, in light of those things, should it be backported to 1.1.X or not? > > Luke > > -- > "Pretension: The downside of being better than everyone else is > that people tend to assume you're pretentious." (despair.com) > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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: decorator_from_middleware change
On Saturday 26 September 2009 20:10:59 kmike wrote: > Not true. cache_page decorator is now documented as putting view > first and timeout second. Take a look at > http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-ca > che Doh, I don't know how I managed to read those several times and not see that! I've fixed it now, thanks! Alex Gaynor reckoned both ways round were possible with previous code. I haven't checked that, but I'll believe him, and I've added compatibility for that. > Another thought. If key_prefix is deprecated in cache_page > decorator maybe it should be also deprecated in CacheMiddleware? It's not 'deprecated' - it was never documented, and therefore never a feature in the first place, and so I didn't see the need to implement it. We could of course re-add it, and document it. As it happens, doing so looks easy. I'm not sure why those arguments are not documented anywhere, either for cache_page or CacheMiddleware, that's why I'm reluctant to add this -- we would then be committing ourselves to supporting something that we might have wanted to remove. Putting specific support for it in cache_page would make it harder to remove. Does anyone else know if we want to expose all the arguments of CacheMiddleware in cache_page? I can easily add them if so. Regards, Luke -- "Smoking cures weight problems...eventually..." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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
2009/9/26 Аркадий Левин : > > Pong. OK - that is rude and complety uncalled for. Johannes has gone to a lot of effort to make a complex proposal; if you aren't going to contribute back in kind, I would kindly ask you to keep your comments to yourself. Johannes - I apologize for not giving you feedback sooner. I've had this on my list of things of to look at for a while, but I keep getting distracted by other things. I will try to get you some feedback in the next day or 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 -~--~~~~--~~--~--~---
