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 fe
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 tim
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 u
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
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
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
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
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 prett
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, the
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 repl
> 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 validatio
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
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-de
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 PositiveIntege
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 toward
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.
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 conclusi
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
rathe
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
19 matches
Mail list logo
