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

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

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=N=%22+%3D+cache_page%22++lang:python=rr_r=lang:python nobody uses

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

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

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

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,

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 >

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

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

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

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

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

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

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

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

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