Re: Proposal: project-specific initial SQL data

Adrian: Thank you for comment. I understood the policy not to creep the features, but let me explain a bit about why I see benefit to have proj_name/sql/app_name/obj_name.sql. Just imagine we have an application comes with initial sql data under the app directory. To customize app-provided ini

Re: Should Django be HTML agnostic?

On 2007-01-11, Rob Hudson wrote: > > 2. The argument against #1 that I've seen is usually that you can > subclass Something and write your own output. But in some ways, this > violates the DRY principle. The code to output a form widget, for > example, is already written, and in looking at what i

Re: Reminder: PyCon early-bird registration ends Monday

I got signed up yesterday. A coworker and I plan on showing up wed. night and staying through the 2nd day of sprints. Will be my first PyCon and first sprint, can't wait! I assume the sprint will be focusing on stomping as many bugs as super-humanly possible? --~--~-~--~~

Re: New Django ticket system workflow ideas

Adrian Holovaty wrote: Hello all, I'd really like to streamline the way we interact with our ticket system, Trac. We've fallen behind on managing tickets, which is not only frustrating to contributors but a hindrance to Django's growth, as solid contributions are made but eventually get lost i

Re: Windows installer

On 1/14/07, Curtis Faith <[EMAIL PROTECTED]> wrote: > > Should we start a separate thread to answer questions like: > > > > * Should we use default Python or something like Portable Python? > > * Assume SQLite? > > * Install any add-ons (like Markdown or Textile)? > > I was pondering these quest

Re: New Django ticket system workflow ideas

On 1/14/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: Hello all, I'd really like to streamline the way we interact with our ticket system, Trac. We've fallen behind on managing tickets, which is not only frustrating to contributors but a hindrance to Django's growth, as solid contributions ar

Re: New Django ticket system workflow ideas

On Sat, 2007-01-13 at 21:09 -0600, Adrian Holovaty wrote: Hello all, I'd really like to streamline the way we interact with our ticket system, Trac. We've fallen behind on managing tickets, which is not only frustrating to contributors but a hindrance to Django's growth, as solid contributions

Re: Windows installer

> Should we start a separate thread to answer questions like: > > * Should we use default Python or something like Portable Python? > * Assume SQLite? > * Install any add-ons (like Markdown or Textile)? I was pondering these questions myself and decided against bundling --- IMHO selecting all t

New Django ticket system workflow ideas

Hello all, I'd really like to streamline the way we interact with our ticket system, Trac. We've fallen behind on managing tickets, which is not only frustrating to contributors but a hindrance to Django's growth, as solid contributions are made but eventually get lost in the sea of half-baked

Re: Windows installer

Rob Hudson wrote: Jacob Kaplan-Moss wrote: Good point. Eugene sent me a windows installer a while ago, but I didn't have a chance to test it out and then I lost track of it Let's table this until closer to the release, but if you want to talk to him and anyone else and start lining things

Re: Proposal: project-specific initial SQL data

On 1/13/07, Yasushi Masuda <[EMAIL PROTECTED]> wrote: Currently we have all initial SQL data under app_dir/sql/. But I think it would be better to add a hook to provide porject-specific initial SQL data somewhere relevant to a project, for example: 1. project_name/sql/app/object_name(.db_engine

Proposal: project-specific initial SQL data

Hello Djangonauts, Currently we have all initial SQL data under app_dir/sql/. But I think it would be better to add a hook to provide porject-specific initial SQL data somewhere relevant to a project, for example: 1. project_name/sql/app/object_name(.db_engine).sql 2. settings.INITIAL_SQL_DA

Re: Moving towards Django 1.0

Hi, Jacob Kaplan-Moss schrieb: On 1/13/07 1:25 PM, Michael Radziej wrote: I'm creating a wiki page for this summary (with some more information). Awesome. I've been keeping a similar list, so I'll fill in what I've got as well. OK, I'm done. http://code.djangoproject.com/wiki/VersionOneFe

Re: Moving towards Django 1.0

On 1/13/07 1:25 PM, Michael Radziej wrote: I'm creating a wiki page for this summary (with some more information). Awesome. I've been keeping a similar list, so I'll fill in what I've got as well. Can somebody fill me in about the tickets for authentication? I'm sure sure ticket-wise, but

Re: newforms feedback?

On 1/13/07, mfremont <[EMAIL PROTECTED]> wrote: I've been working on my first non-trivial Django app using newforms and, in general, I found it much easier to work with than the forms/manipulators from 0.95. Is this the right place to offer detailed feedback? definitely I have some specific

newforms feedback?

I've been working on my first non-trivial Django app using newforms and, in general, I found it much easier to work with than the forms/manipulators from 0.95. Is this the right place to offer detailed feedback? I have some specific comments about the API, which include some suggestions for impro

Re: Windows installer (was: Moving towards Django 1.0)

Jacob Kaplan-Moss wrote: > Good point. Eugene sent me a windows installer a while ago, but I didn't have > a chance to test it out and then I lost track of it > > Let's table this until closer to the release, but if you want to talk to him > and anyone else and start lining things up for a wi

Re: Moving towards Django 1.0

Hi, please don't forget that every feature that you propose and that gets into the 1.0 list will delay 1.0. Everybody has their favorite pet, and with any project and any milestone, its the same: everybody tries to push their favorites in. The most important goal of 1.0 are stable APIs, i.e. tha

Re: File upload in newforms

On 1/11/07, Sergey Kirillov <[EMAIL PROTECTED]> wrote: > I'm missing something or there is no file upload support in newforms? Use the FileInput widget to use . Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this m

Re: how to specify the location of image in src?

This is a django users question. You need to serve the media separately. See http://www.djangoproject.com/documentation/static_files/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To p

custom settings for tests

Ok, Here is something I was thinking about and I would like to see if anybody else had a similar need, or if I am just missing something. When writing unit tests, in a similar way to having fixtures as proposed in http://code.djangoproject.com/ticket/2333 I would like to have custom settings dat

Using Capistrano to Deploy/Maintain Django Applications

Has anyone used Capistrano with Django? I have been looking for documentation, and the Cap manual uses RoR for its examples - it's not very approachable for someone doing application deployment outside of that framework. I've found sparse information on deploying non-Rails apps, but I've had a ha

Re: File upload in newforms

Hi again, Could not find a ticket about that so I opened one, #3297 Cheers, Marc. On 1/11/07, Sergey Kirillov <[EMAIL PROTECTED]> wrote: > > > I'm missing something or there is no file upload support in newforms? > > > > > --~--~-~--~~-

Re: Moving towards Django 1.0

Jacob Kaplan-Moss wrote: > * Forms: the newforms library is coming along nicely. There's some work that > remains, the bulk of which lies in converting the admin to use newforms > instead of manipulators. At that point, the transition can really be called > complete. it seems that noone ment

Re: Moving towards Django 1.0

The main thing i'm missing is a workable reversed url resolver. Or at least an easy way to define/extend the current implementation. There was already some discussion about it (see Proposal: Root view). As it seems such a thing, while being said to be backwards compatible, change the current way u

Re: Configuration Refactoring

Would like to suggest renaming MEDIA_ROOT to DOCUMENT_ROOT. For some Apache users, this might feel more natural, and should ease up the learning process too. +1 for DOCUMENT_ROOT =) Etienne --~--~-~--~~~---~--~~ You received this message because you are subscrib

Re: Configuration Refactoring

On Jan 13, 6:26 pm, "Gil Pinheiro" <[EMAIL PROTECTED]> wrote: > MEDIA_* is poorly named since they overload the meaning of 'media' > which otherwise relates back to the static css/img/js content. > MEDIA_UPLOAD, or something else would be clearer. If this is not > changed then the description need

Re: Autoescaping for 1.0

On Jan 13, 10:23 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I think > Chris's idea misses a bunch of the subtleties (and that isn't a > criticism of him writing the proposal, since he has laid out his point > of view clearly and offered a solution without any fuss, rather than > continual

Re: Autoescaping for 1.0

On Sat, 2007-01-13 at 06:29 +, Brian Beck wrote: > Jeremy Bowers wrote: > > I've also discovered that even relatively skilled developers can have a > > lot of trouble catching every case that needs to be escaped, whereas > > almost any developer can correctly determine when *not* to escape > >

Re: Autoescaping for 1.0

On Fri, 2007-01-12 at 23:28 -0800, Nicola Larosa (tekNico) wrote: > On 13 Gen, 06:02, "SmileyChris" <[EMAIL PROTECTED]> wrote: > > We need to come to a consensus on Django autoescaping > > There's an interesting discussion on GvR's blog, with several mentions > of escaping: > > http://www.artima

Re: Moving towards Django 1.0

It's good to see some push towards 1.0 > == Feedback == What about one-to-one relationships? They seem to have had a deprecated status for some time now. In addition to organizing the documentation, I'd also like to see some cleaning up and reorganization in the wiki. It also should be at least