Re: What The Enterprise wants from Django

On 19.01.2010 23:26, Jacob Kaplan-Moss wrote: > Finally, we ruminated over the difficulties in building rich internet > applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, > but we doesn't really have a good answer for the people who want > something IDE or GUI-ish. Meanwhile,

Re: What The Enterprise wants from Django

On 21 Jan., 17:45, Andy McKay wrote: > On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote: > > > I agree that managing settings gets to be a bit difficult in many > > environments - even non Fortune 1000 environments. Its also an issue for us that write and use

Re: What The Enterprise wants from Django

On Jan 20, 3:15 pm, sago wrote: > I've had one very long and complex issue with a major client over > legacy databases with Composite Primary Keys (and other composite keys > more generally), an issue which has also come up in other contexts. > One of my smaller

Re: What The Enterprise wants from Django

On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote: > I agree that managing settings gets to be a bit difficult in many > environments - even non Fortune 1000 environments. One of the things > we've played with in Satchmo is a database backed solution that allows > you to define reasonable

Re: What The Enterprise wants from Django

Hi! My previous experience was from Java J2EE world and as Jacob said we adopted Django because it really shines solving some complexity problems associated to J2EE world as MVC patter, templates, etc., but I agree that a common way to configure external applications would be nice. I'll also

Re: What The Enterprise wants from Django

I agree that managing settings gets to be a bit difficult in many environments - even non Fortune 1000 environments. One of the things we've played with in Satchmo is a database backed solution that allows you to define reasonable defaults - even override-able in the settings - but allow people to

Re: What The Enterprise wants from Django

On Thu, Jan 21, 2010 at 10:24 AM, sago wrote: > Case studies are helpful if folks can share them. Just a quick note that the DSF is working on gathering case studies; getting folks who have permission to share is indeed a tricky issue. Not much is set up yet, but I,

Re: What The Enterprise wants from Django

On Thu, Jan 21, 2010 at 8:58 AM, Luke Plant wrote: > I would have guessed that a big issue with Django from an enterprise > perspective is its use of 'singletons'. [snip] > How much is this an issue in practice? Other than databases, it hasn't been much of an issue with

Re: What The Enterprise wants from Django

> I would have guessed that a big issue with Django from an enterprise > perspective is its use of 'singletons'. > > How much is this an issue in practice?   Yes, that's been my experience. For complex deployments with tens or hundreds of apps, it is often the case that it is absolutely essential

Re: What The Enterprise wants from Django

On Jan 21, 2010, at 9:58 AM, Luke Plant wrote: > On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote: > >> So there we are. This is very much a brain dump, and I don't really >> expect any concrete action to result from it. However, I found some >> really interesting stuff there, and I

Re: What The Enterprise wants from Django

On Tuesday 19 January 2010 21:26:17 Jacob Kaplan-Moss wrote: > So there we are. This is very much a brain dump, and I don't really > expect any concrete action to result from it. However, I found some > really interesting stuff there, and I thought I'd share. Thanks for your clarification

Re: What The Enterprise wants from Django

2010/1/21 Russell Keith-Magee : > > It strikes me that this is just one example of a whole class of "best > practice" stuff that we should document, but don't at present - like > project layout, automated deployment, continuous integration, > configuration management, etc.

Re: What The Enterprise wants from Django

2010/1/20 Jacob Kaplan-Moss : > On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote: >> I don't understand how avoiding the settings.py mechanism will produce >> *more* flexibility. > > The problem -- at least as I see it -- is that of a intertwingulment

Re: What The Enterprise wants from Django

On Thu, Jan 21, 2010 at 2:54 AM, Jacob Kaplan-Moss wrote: > On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote: >> I don't understand how avoiding the settings.py mechanism will produce >> *more* flexibility. > > The problem -- at least as I see it --

Re: What The Enterprise wants from Django

Using djangorecipe and zc.buildout offer your exactly that kind of mechanism. You write the name of settings of choice in your buildout: [django] recipe = djangorecipe version = 1.1 settings = development eggs = ${eggs:eggs} wsgi = true project = project And after that you can have by example

Re: What The Enterprise wants from Django

> I don't understand how avoiding the settings.py mechanism will produce > *more* flexibility. Bad choice of words on my part, sorry. Of course code is always more flexible than static data. The two key bits of required 'flexibility' I didn't have out of the box (and were difficult to hack and

Re: What The Enterprise wants from Django

On 2010-01-20, at 10:54 AM, Jacob Kaplan-Moss wrote: On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote: I don't understand how avoiding the settings.py mechanism will produce *more* flexibility. The problem -- at least as I see it -- is that of a intertwingulment

Re: What The Enterprise wants from Django

> A lack of any mechanism for developers to understand what third party > apps are reliable, what to avoid, known problems, and so on. This has > been a particular complaint since the Django ethos is (rightly) that > the core is the core, and other functionality should be packaged into > third

Re: What The Enterprise wants from Django

On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote: > I don't understand how avoiding the settings.py mechanism will produce > *more* flexibility. The problem -- at least as I see it -- is that of a intertwingulment of "application" settings with "ops" settings. As

Re: What The Enterprise wants from Django

On Wednesday 20 January 2010 17:15:39 sago wrote: > Startup and Settings are the big killers though, head and shoulders > above the previous issues. I've nothing much to add to your > comments other than to say that some of the Django deployments I > know of are highly heterogeneous, with

Re: What The Enterprise wants from Django

I also work with several fortune 500 clients (though not specifically as a Django consultant, Django is a preferred tool) and the issues your client mentions, Jacob, are very similar to those I deal with. Some other notes from the concerns of multinational clients: I've had one very long and

Re: What The Enterprise wants from Django

On Jan 19, 4:26 pm, Jacob Kaplan-Moss wrote: > The next big one was the "startup signal" issue -- they've got lots of > code that needs to run at startup time, and there's no great mechanism > to do that currently. The core devs have talked about this one a *lot* > over the

Re: What The Enterprise wants from Django

Startup signal - when using mod_wsgi the wsgi init app can be a good place to call the startup work, starting threads, setting logging level etc. It worked for me, but it's probably much simpler than a complex corporate deployment. On Jan 19, 11:26 pm, Jacob Kaplan-Moss

Re: What The Enterprise wants from Django

On Jan 20, 5:59 am, David Cramer wrote: > The first three have been huges ones with us. We're just now running > into the settings issue, but would love to see what people can come up > with for solutions (we dont have a good one). The override_settings() idea that Eric

Re: What The Enterprise wants from Django

The first three have been huges ones with us. We're just now running into the settings issue, but would love to see what people can come up with for solutions (we dont have a good one). Glad to see multi db is finally shipping, and excited to see what can be done for startup procs. On Jan 19,

What The Enterprise wants from Django

Hi folks -- I had a conversation this morning with one of my clients. In the interests of being a good corporate citizen I'll refrain from mentioning who other than (a) they're big (Fortune 1000), (b) you've heard of them, and (c) they're using Django. Before our chat, they'd invited any