Re: newforms-admin _display_login_form and other as function?

OK, I wasn't sure, if there is not some reason for this - and for asking is better forum than ticket ;-). I'll try create a ticket. Glin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: How submit a patch with files not in subversion?

On 8/2/07, mamcx <[EMAIL PROTECTED]> wrote: > > The point is that I don't have write permissions on the subversion > tree... But you should still be able to svn add, which will allow svn diff to create a patch that contains the new files. svn add is a local operation, not a server operation. And

Re: How submit a patch with files not in subversion?

On 8/1/07, mamcx <[EMAIL PROTECTED]> wrote: > > The point is that I don't have write permissions on the subversion > tree... You don't need write permission on the repository to do svn add, it's just a local working copy change. Like any modifications, you won't be able to commit them directly t

Re: How submit a patch with files not in subversion?

On Thu, Aug 02, 2007 at 01:38:00AM -, mamcx wrote: > The point is that I don't have write permissions on the subversion > tree... This tells subversion to start caring about file myfile.py: svn add myfile.py After you've done that, this will include myfile.py in your diff: svn diff You don

Re: How submit a patch with files not in subversion?

The point is that I don't have write permissions on the subversion tree... --~--~-~--~~~---~--~~ 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@googlegro

Re: Supported versions of databases

On 8/2/07, Don Arbow <[EMAIL PROTECTED]> wrote: > > I am running Django with PostgreSQL 7.3.3. The get_sql_flush() method > in django/db/backends/postgresql/base.py uses "ALTER SEQUENCE", > rather than the older "SELECT setval()". This method was added for > the test system's fixture loading. I pa

Re: Supported versions of databases

On Aug 1, 2007, at 9:14 AM, Malcolm Tredinnick wrote: > > - There are still people using PostgreSQL 7.x. Anything prior to > 7.3 is > probably too hard to support. Setting the bar at 7.3 or 7.4 might be > reasonable (I can't remember any big changes between those two). > 8.0 is > too recent, s

Re: select_related additions

Seems I slipped in the diff. I have to actually apply the patch to at least 2 different versions of Django with our current setup, can get tedious :P *args should be *fields :) On Aug 1, 9:26 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > On Wed, Aug 01, David Cramer wrote: > > > I've submitte

Re: How submit a patch with files not in subversion?

On 8/2/07, mamcx <[EMAIL PROTECTED]> wrote: > > For that, I create a new backend in called "mssql". I create a patch > with tortoise svn and test if can be applied but tortoisesvn complain > in the files not in subversion (that it, all the new files of the > mssql backend). > > What to do in this

How submit a patch with files not in subversion?

Hi, related to http://groups.google.com/group/django-developers/browse_thread/thread/c7029442e8a47079 I made the first steps. I have working (more or less) the ms-sql backend with pymssql and can create the tables and run the admin with no errors of the tutorial app. For that, I create a new b

Re: full Atom Publishing Format support almost done

On Aug 1, 5:21 pm, James Tauber <[EMAIL PROTECTED]> wrote: > As of r11, the full data model for the Atom Format (RFC 4287) is now > implemented. Great stuff. How easy is it to extend feeds with additional attributes, e.g. for Google Base? Jason --~--~-~--~~~---~--~

Re: Autoescaping: good time?

On Aug 1, 7:31 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > We've seen how bad XSS can be; I think we have an almost moral obligation > here. Agreed; I'm +1 on this proposal for this reason. Genshi [1] seems to do a similar thing: autoescape is on by default. Jason [1] http://genshi.

Re: Autoescaping: good time?

James Bennett wrote: > Let's just do: > > 1. Autoescape on by default. > 2. Autoescape is turned off by the {% autoescape off %} > 3. Autoescape happens irregardless of what the template's source file > or source string happened to be named. Is it done yet? --~--~-~--~~~

Re: Autoescaping: good time?

On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > Thank you for taking this opportunity to remind me of the autoescaping > proposal. I must have forgotten it somewhere along the way here. > (Next time, you *could* just say you're -1.) :P I'm just saying: let's do this. Malcolm's right: the amo

Re: Autoescaping: good time?

On 8/1/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > Let's assume autoescaping is on unless the template engine knows > > otherwise; your inline templates will work as expected both before and > > after extraction (again, assuming you're extra

Re: Ticket #3700: XhtmlDegraderMiddleware

Jacob Kaplan-Moss wrote: > > Nice stuff -- think I'll be using this a few times. > > However, I'd say that it's a *bit* too specialized for direct > inclusion; while I personally find it useful, I'm just suspicious of > including anything in Django that doesn't have obvious wide appeal. > > I'd

Re: Autoescaping: good time?

On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > Let's assume autoescaping is on unless the template engine knows > otherwise; your inline templates will work as expected both before and > after extraction (again, assuming you're extracting them to a file > ending in ``.html``). Let's just do:

Re: Autoescaping: good time?

On 8/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Anybody who thinks this decision is actually a really big life-changing > decision needs to re-evaluate their priorities. And perhaps pick some > bigger-item bugs to fix. This is too depressing; just pick one and move > on. Translating

Re: Autoescaping: good time?

On 8/1/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Wednesday 01 August 2007 19:56:05 Tom Tobin wrote: > > Okay, post-Starbucks chat with my co-workers, here's my last-ditch > > mitigation proposal: > > > > Set autoescaping on by default for anything ending in ``.html`` (and, > > perhaps, ``.h

Re: Autoescaping: good time?

On Wed, 2007-08-01 at 14:00 -0500, Jacob Kaplan-Moss wrote: [...] > So, given that, I'm pretty happy with Tom's mini-counter-proposal. It > might take some nasty hacking to "remember" where a template was > loaded from (not sure; gotta check), but not having < show up in > ".txt" templates would b

Re: Autoescaping: good time?

On Wednesday 01 August 2007 19:56:05 Tom Tobin wrote: > Okay, post-Starbucks chat with my co-workers, here's my last-ditch > mitigation proposal: > > Set autoescaping on by default for anything ending in ``.html`` (and, > perhaps, ``.htm``), and off otherwise. -1 on this, it's much too magic for

DjangoForge [was: Ticket #3700: XhtmlDegraderMiddleware]

On 8/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I was working on a "DjangoForge" app repository for a few weeks > leading up to PyCon, and had a working prototype that I was showing > around. I was trying to push the idea at the time, but there just > didn't seem to be the interest and/

Re: Ticket #3700: XhtmlDegraderMiddleware

BTW, I apologize for the now-complete derailment of the thread. -Eric Florenzano On Aug 1, 12:42 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I was working on a "DjangoForge" app repository for a few weeks > leading up to PyCon, and had a working prototype that I was showing > around. I

Re: Ticket #3700: XhtmlDegraderMiddleware

I was working on a "DjangoForge" app repository for a few weeks leading up to PyCon, and had a working prototype that I was showing around. I was trying to push the idea at the time, but there just didn't seem to be the interest and/or agreement on what exactly it should do. Hopefully this SoC p

Re: Autoescaping: good time?

On 8/1/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > From a user's point of view, it sucks even harder. So you install that > cool PHP forum everyone's been crowing about. In the process, you turn > off magic_quotes like the docs tell you too. A few months later, you > install new blog softwa

Re: Autoescaping: good time?

On 8/1/07, Deryck Hodge <[EMAIL PROTECTED]> wrote: > May I ask a clarifying question here? Is autoescaping going to be on > by default, or no? And what exactly is it that's being added here -- > a template tag for turning on/off autoescaping? Yes, the plan is to have autoescaping on unless you

Re: Autoescaping: good time?

On 8/1/07, Deryck Hodge <[EMAIL PROTECTED]> wrote: > May I ask a clarifying question here? Is autoescaping going to be on > by default, or no? And what exactly is it that's being added here -- > a template tag for turning on/off autoescaping? The proposal is: * Autoescaping is on by default. *

Re: Autoescaping: good time?

On 8/1/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Is autoescaping being on *really* that big a deal to you? How many > places do your variables actually contain HTML? And if the answer is > "many", then is it really all that big a deal to make a one-time > modification to your base templat

Re: Autoescaping: good time?

On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > Okay, post-Starbucks chat with my co-workers, here's my last-ditch > mitigation proposal: M Starbucks Yes, we had quite a good little argument about all this. It's a tricky problem; it feels like the only way to get this right is to p

Re: Autoescaping: good time?

Okay, post-Starbucks chat with my co-workers, here's my last-ditch mitigation proposal: Set autoescaping on by default for anything ending in ``.html`` (and, perhaps, ``.htm``), and off otherwise. Being (at least ideally) language-neutral has precedent in Django; we've already moved away from ass

Re: Autoescaping: good time?

On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > I've only had a chance to take a brief look at the latest changes on > that ticket (and I'm seeing a bunch of patches that are showing as > blank in Trac for some reason), so I'm speaking a bit from ignorance > here. I can probably live at -0 with

Re: Autoescaping: good time?

On 8/1/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I felt my hackles rising until I read this part. ^_^ I'm somewhere > > between -0 and +0 at this point so long as auto-escaping is off by > > default (and -1 otherwise, as per my objection

Re: Autoescaping: good time?

On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > I felt my hackles rising until I read this part. ^_^ I'm somewhere > between -0 and +0 at this point so long as auto-escaping is off by > default (and -1 otherwise, as per my objections in previous > discussions on the topic). I still don't like

Re: Ticket #3700: XhtmlDegraderMiddleware

On 8/1/07, Forest Bond <[EMAIL PROTECTED]> wrote: > Surely, you were thinking of Cheese Shop, right? :) Sure, but without all the sucky parts :P [There are, BTW, some Django-specific things that make direct Cheese Shop integration a bit tricky, but there's an SoC project working on that, so hope

Re: Ticket #3700: XhtmlDegraderMiddleware

On Wed, Aug 01, 2007 at 11:29:44AM -0500, Jacob Kaplan-Moss wrote: > Of course, what we really need is a CPAN-for-Django-bits-thingie... I > wish there was a middle ground between "included" and "not." Surely, you were thinking of Cheese Shop, right? :) Seriously, though, how many special-purpose

Re: Ticket #3700: XhtmlDegraderMiddleware

Hi Dave -- > A while back I wrote some middleware to improve XHTML usage > . Is this something that > could or should be included within Django? Nice stuff -- think I'll be using this a few times. However, I'd say that it's a *bit* too specialized for

Re: select_related additions

On Wed, Aug 01, David Cramer wrote: > > I've submitted a ticket and attached part of the patch (the fields > selection on select_related): http://code.djangoproject.com/ticket/5020 Funny, I'm working on something similar. I don't understand how the new API looks like, and particularily how thi

Re: Supported versions of databases

On 8/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > - Oracle 10 (check with Boulder guys, but I think that was the minimum). > The cx_Oracle minimum version is documented in install.txt. We developed against Oracle 9i and 10g, and so Oracle 9i is sufficient for the most part. The only fea

Re: full Atom Publishing Format support almost done

As of r11, the full data model for the Atom Format (RFC 4287) is now implemented. On 31/07/2007, at 4:19 AM, James Tauber wrote: > > As described here[1], I finally got around to working on improving > django support for the Atom Publishing Format. There's been a ticket > [2] for this since Py

Re: select_related additions

I've submitted a ticket and attached part of the patch (the fields selection on select_related): http://code.djangoproject.com/ticket/5020 On Jul 30, 12:39 pm, David Cramer <[EMAIL PROTECTED]> wrote: > I have taken a bit of time to rewrite part of the QuerySet code > (including select_related). P

Re: Supported versions of databases

On Wed, 2007-08-01 at 13:09 +0200, Nis Jørgensen wrote: > The django documentation currently only mentions supported/recommended > versions for mySQL, not for the other databases. > > I think it would be a good idea to have > > - documentation of supported versions for all databases (including >

Re: Autoescaping: good time?

Hey Michael, On Wed, 2007-08-01 at 16:51 +0200, Michael Radziej wrote: > On Wed, Aug 01, Jacob Kaplan-Moss wrote: > > > > > On 8/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > since the unicode waves have calmed down, wouldn't it be a nice time to > > > include the autoescaping patch? >

Re: Autoescaping: good time?

On 8/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Auto-escaping is off by default, so there shouldn't be any compatibility > issues at all. I felt my hackles rising until I read this part. ^_^ I'm somewhere between -0 and +0 at this point so long as auto-escaping is off by default (and

Re: Autoescaping: good time?

On Wed, Aug 01, Jacob Kaplan-Moss wrote: > > On 8/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > since the unicode waves have calmed down, wouldn't it be a nice time to > > include the autoescaping patch? > > Malcolm, Simon and I talked about this at OSCON, and I'm now > convinced. I'd li

Re: newforms-admin _display_login_form and other as function?

Hi Glin -- Newforms-admin is very much a work-in-progress; warts like the ones you describe are to be expected. The best thing to do now is file a ticket; the more we know about "use cases" for newforms-admin, the better we'll be able to handle 'em. Jacob --~--~-~--~~~--

Re: Autoescaping: good time?

On 8/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > since the unicode waves have calmed down, wouldn't it be a nice time to > include the autoescaping patch? Malcolm, Simon and I talked about this at OSCON, and I'm now convinced. I'd like to have Malcolm look over your work, Michael, and make

Autoescaping: good time?

Hi, since the unicode waves have calmed down, wouldn't it be a nice time to include the autoescaping patch? I've brought most of the patches in ticket #2359 up to date. There are 3 patches, the first two deal with implementing autoescape as discussed and based on original ideas from Simon Willis

newforms-admin _display_login_form and other as function?

Hi, I'm using newforms-admin branch, as it aim to be easily customizable (besides that oldforms will be removed soon). It is really useful to have classes such as ModelAdmin or AdminSite. But sometimes I have feeling like author went against main moto of newforms-admin branch and did such design,

Re: How to validate a model as a whole?

On 8/1/07, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > It has come to my attention that there seems to be no "real" way of > validating a model instance as a unit, I mean with a custom validator > on a field, you can at -- without doing black magic -- validate the > model's "raw" field data. I'm

How to validate a model as a whole?

Hello, It has come to my attention that there seems to be no "real" way of validating a model instance as a unit, I mean with a custom validator on a field, you can at -- without doing black magic -- validate the model's "raw" field data. What I need is a way to check stuff against foreign model

Re: Tickets for comment/BDFL approval

On 8/1/07, Gary Wilson <[EMAIL PROTECTED]> wrote: > > authors = Author.objects.filter(name__contains="Gary") > new_book = Book(title="Hello World", authors=authors) > new_book.save() Regardless of any particular merits of this idea, it has one _huge_ strike against it - it's a _massive_ backwards

Supported versions of databases

The django documentation currently only mentions supported/recommended versions for mySQL, not for the other databases. I think it would be a good idea to have - documentation of supported versions for all databases (including shortcomings of the older versions) - similar to what is available fo