Re: Proposal: Optional {% default %} clause for the {% for %} template tag
How about
{% for item in items %}
{% otherwise %}
{% endfor %}
form?
And -1 for the {% else %}.
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Optional {% default %} clause for the {% for %} template tag
+1 for {% empty %}
I also think this would be very useful
On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
>
> How about
>
> {% for item in items %}
> {% otherwise %}
> {% endfor %}
>
> form?
>
> And -1 for the {% else %}.
>
> >
>
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Optional {% default %} clause for the {% for %} template tag
2008/10/30 Mike Panchenko <[EMAIL PROTECTED]>:
> +1 for {% empty %}
>
> I also think this would be very useful
>
> On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
>>
>> How about
>>
>> {% for item in items %}
>> {% otherwise %}
>> {% endfor %}
>>
+1 to the otherwise tag :)
--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Ticket #9405 - Thoughts?
I wanted to bring this up here on the mailing list, as I doubt much discussion will take place on a ticket which was closed as "wontfix". I added a comment to the ticket after it was closed as to my reasoning behind the ticket and associated patch, and I wanted to see what other people have to say on the subject. The patch itself is small, harmless (afaict) and potentially very helpful. Any input is welcome! --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: Manage.py custom commands overloading
Hi Guys, While trying out a new WSGI handler, that should run fine in the usual command line "runserver", i noticed that the get_commands() in managment.__init__ does not look for commands in the top level directory. suppose things are set up as follows /project/ /app1/ /app2/ manage.py settings.py the get_commands will look into each app to find commands but not the 'project' level. But also if an app defined a "core" command, it does not 'overload' the core one (i.e. say 'runserver' for instance). So the proposal is this 1) Add the ability to define a "project" command in the root directory (which is _not_ app dependent) 2) reverse the load order of get_commands to start from the App --> Project --> core i.e. ... /django/core/management/comands/ blaa.py -- load #3 /project/ /management/ /commands/ blaa.py -- load #2 /app1/ /management/ /commands/ blaa.py -- load #1 the reason why this might be handy is the project an control various inter-relations between apps and also use some 'other' WSGI handlers in runserver or different FCGI handlers thoughts? --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Optional {% default %} clause for the {% for %} template tag
{% for color in patches %}
Bikeshed: {{ color }}
{% default %}
Person who writes the patch decides
{% endfor %}
I like empty/default or else. Use else if your main target is python people.
Use empty or default if your targetting it to designers. It really doesn't
matter which..
On Thu, Oct 30, 2008 at 12:29 PM, Antoni Aloy <[EMAIL PROTECTED]> wrote:
>
> 2008/10/30 Mike Panchenko <[EMAIL PROTECTED]>:
> > +1 for {% empty %}
> >
> > I also think this would be very useful
> >
> > On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
> >>
> >> How about
> >>
> >> {% for item in items %}
> >> {% otherwise %}
> >> {% endfor %}
> >>
>
> +1 to the otherwise tag :)
>
>
> --
> Antoni Aloy López
> Blog: http://trespams.com
> Site: http://apsl.net
>
> >
>
--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Absolute paths in settings.py
Hi, There are a couple of things in settings.py that require an absolute path. I don't know about you, but I tend to put all things related to a project in subdirectories under the project directory. Thus all the absolute paths have the same prefix, the project directory. Rather than going trough the hassle of maintaining this by hand, I have begun using the following snippet: PROJECT_DIR = os.path.abspath(os.path.dirname(__file__)) then for instance MEDIA_ROOT = os.path.join(PROJECT_DIR, 'media') and TEMPLATE_DIRS = ( # Always use forward slashes, even on Windows. os.path.join(PROJECT_DIR, 'templates/'), ) Would it make sense to put this or something like it in Django? Ole --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
I would like to see this, it seems to be an idiom that most people use. I know i have to implementent that exact same thing for every project I have ever done with django. On Thu, Oct 30, 2008 at 1:34 PM, Ole Laursen <[EMAIL PROTECTED]> wrote: > > Hi, > > There are a couple of things in settings.py that require an absolute > path. I don't know about you, but I tend to put all things related to > a project in subdirectories under the project directory. Thus all the > absolute paths have the same prefix, the project directory. Rather > than going trough the hassle of maintaining this by hand, I have begun > using the following snippet: > > PROJECT_DIR = os.path.abspath(os.path.dirname(__file__)) > > then for instance > > MEDIA_ROOT = os.path.join(PROJECT_DIR, 'media') > > and > > TEMPLATE_DIRS = ( ># Always use forward slashes, even on Windows. >os.path.join(PROJECT_DIR, 'templates/'), > ) > > Would it make sense to put this or something like it in Django? > > > Ole > > > > --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #9405 - Thoughts?
On Thu, Oct 30, 2008 at 11:42 AM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > The patch itself is [...] potentially very helpful. How so? Be specific: we don't add things to Django because of their "potential" use; we add things because of actually problems. What, exactly, would this patch let you do that you can't currently? Jacob --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Manage.py custom commands overloading
On Thu, Oct 30, 2008 at 11:53 AM, bo <[EMAIL PROTECTED]> wrote: > While trying out a new WSGI handler, that should run fine in the usual > command line "runserver", i noticed that the get_commands() in > managment.__init__ does not look for commands in the top level > directory. This is by design: Django looks for custom commands in INSTALLED_APPS only. "Projects" have no real special standing as far as Django is concerned -- in fact, it's entirely possible to deploy a site without a "project" at all. IOW, "project" is pretty much an abstraction to help us humans organize things; Django doesn't care. If you've got a command that you want to be available, factor it out into an app and add it to INSTALLED_APPS. Jacob --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #9405 - Thoughts?
This patch was one essential step I had to make in an application I am developing to be able to connect to both PostgreSQL and MS SQL databases concurrently. My Django configuration is stored in PostgreSQL and therefore is where django.db.connection points. I am accessing data on the MS SQL servers, however, through a custom manager. When performing database operations on the MS SQL connections, the operations class for PostgreSQL would instead be called, because there are several things in DatabaseOperations which reference django.db.connection. With this patch, everything is moved to use self.connection instead and the world is happier. :) Malcolm said in his response to the ticket, "It's not immediately clear that it's the right approach for multiple database support." However, I believe that I'm not offering a particular solution or approach to fully implementing multiple database support; this is simply something which will make the integration easier regardless of what approach is decided upon. It's already been proven to work in my own case, and I can't see any reason it wouldn't work with any other implementation. On Thu, Oct 30, 2008 at 11:53, Jacob Kaplan-Moss <[EMAIL PROTECTED] > wrote: > > On Thu, Oct 30, 2008 at 11:42 AM, Joey Wilhelm <[EMAIL PROTECTED]> > wrote: > > The patch itself is [...] potentially very helpful. > > How so? Be specific: we don't add things to Django because of their > "potential" use; we add things because of actually problems. What, > exactly, would this patch let you do that you can't currently? > > Jacob > > > > --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Manage.py custom commands overloading
On Oct 30, 11:55 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > > This is by design: Django looks for custom commands in INSTALLED_APPS > only. "Projects" have no real special standing as far as Django is > concerned -- in fact, it's entirely possible to deploy a site without > a "project" at all. IOW, "project" is pretty much an abstraction to > help us humans organize things; Django doesn't care. so i suppose you don't consider "django" to be the "master project" then? :) > > If you've got a command that you want to be available, factor it out > into an app and add it to INSTALLED_APPS. > yes, that's what i'm doing currently, but it feels like its in the wrong place. to pose the question: Why would "syncdb" sit in the App level and not the project level? (and if you think of 'django' as the base-project it already sits at a project level) Even if you think multi-app commands should sit in an app structure of its own .. One still cannot overload the 'base' commands. Sure 'runserver' could be 'app' specific, but 90% of the time its usually multi-app specific. Leaving no real options for a custom handler. (without writing a "runMyFancyserver" command in an "app" that's not really an app .. ). Then if one 'can' overload the base command what should be the precedence order? should 2 apps defined "runserver" who wins .. usually the 'last guy in the load order' i would assume. Then if one allows the 'project' level (however you define it) who should take precedence? or should "all" of them be run or some mechanism in place the determines the proper one? Or should there be certain commands that "concat" and some that cannot? "cleanup" .. where a "contrib" (sessions) has somehow got stuck into the "core". could then be included in an App as a multi-run command "runserver" .. need some way of figuring out "who wins" (either via an option or some guess based on position in an over all import structure) "syncdb" .. can easily run over then entire project, but if a app has its own syncdb run that one instead of the default one. I'm sure the commands are rarely overloaded or even too far messed with (the documentation says to look at the code). I'm just posing the question/suggestion. bo --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
It would be useful to have at least this one by default: PROJECT_DIR = os.path.abspath(os.path. dirname(__file__)) Other defaults such as MEDIA_ROOT and TEMPLATE_DIRS also would be useful for me as I repeat these exact lines for every project. Regards, Valts. On Thu, Oct 30, 2008 at 8:44 PM, matt westerburg <[EMAIL PROTECTED]>wrote: > I would like to see this, it seems to be an idiom that most people use. I > know i have to implementent that exact same thing for every project I have > ever done with django. > > > On Thu, Oct 30, 2008 at 1:34 PM, Ole Laursen <[EMAIL PROTECTED]> wrote: > >> >> Hi, >> >> There are a couple of things in settings.py that require an absolute >> path. I don't know about you, but I tend to put all things related to >> a project in subdirectories under the project directory. Thus all the >> absolute paths have the same prefix, the project directory. Rather >> than going trough the hassle of maintaining this by hand, I have begun >> using the following snippet: >> >> PROJECT_DIR = os.path.abspath(os.path.dirname(__file__)) >> >> then for instance >> >> MEDIA_ROOT = os.path.join(PROJECT_DIR, 'media') >> >> and >> >> TEMPLATE_DIRS = ( >># Always use forward slashes, even on Windows. >>os.path.join(PROJECT_DIR, 'templates/'), >> ) >> >> Would it make sense to put this or something like it in Django? >> >> >> Ole >> >> >> > > > > --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
On Thu, Oct 30, 2008 at 10:06:17PM +0200, Valts Mazurs wrote: > It would be useful to have at least this one by default: > PROJECT_DIR = os.path.abspath(os.path. dirname(__file__)) If django where to ship something like this __file__ would point to somewhere within the installation folder of django, which is obviously not what we want. For this to even be considered (IMO) someone would have to present a workaround for this issue first :) -- Thomas Kongevold Adamcik --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
On 10/30/08, Thomas K. Adamcik <[EMAIL PROTECTED]> wrote: > If django where to ship something like this __file__ would point to somewhere > within the installation folder of django, which is obviously not what we > want. Not necessarily true. If this code were in the settings.py from the project_template it would get laid down in your project when you ran django-admin.py startproject, which is, I think, the appropriate place for this relative path stuff to land. See: http://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py +1 from me. :) -Rob --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
On Thu, Oct 30, 2008 at 3:20 PM, Rob Hudson <[EMAIL PROTECTED]> wrote: > Not necessarily true. If this code were in the settings.py from the > project_template it would get laid down in your project when you ran > django-admin.py startproject, which is, I think, the appropriate place > for this relative path stuff to land. Except for the part where it breaks/causes headaches for eggs and zipped packages, both of which are somewhat popular in this Python world. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
David, What is the current status of this patch? I'm starting up a new project which pretty much desperately needs this support as well. I could work around it, but the thought of adding AutoFields to all of these models which really -do not- need them, makes me a bit ill. I would be more than willing to help test your implementation if there is anything usable yet. This is one of the pieces that's getting me all twitchy waiting for it. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
It allows you to use them, automatically creates them, and has some of the admin handling done. However, there's still no API design around multi-column fields (no one seems to want to talk about it) so I'm pretty much stopped working on it. e.g. You can't say field1 = this, field2 = that, and then say compositekey = field1,field2 you instead are forced to do key1=blah, key2=blah in all your lookups, and no easy foreignkey properties. I'm running this on production environments, so it works fine, but I can up SVN and fix any conflicts and post a patch again. On Thu, Oct 30, 2008 at 3:40 PM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > > David, > > What is the current status of this patch? I'm starting up a new > project which pretty much desperately needs this support as well. I > could work around it, but the thought of adding AutoFields to all of > these models which really -do not- need them, makes me a bit ill. > > I would be more than willing to help test your implementation if there > is anything usable yet. This is one of the pieces that's getting me > all twitchy waiting for it. > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
That would be great. The project I am working on now won't be doing anything too terribly complex just yet; I mainly need the admin support to make my life a little easier. As to the API, I saw several proposals earlier along on this thread, but obviously nothing solid. Did anything ever come from DjangoCon on this topic? What issues still need to be addressed in this design? On Thu, Oct 30, 2008 at 13:46, David Cramer <[EMAIL PROTECTED]> wrote: > It allows you to use them, automatically creates them, and has some of the > admin handling done. However, there's still no API design around > multi-column fields (no one seems to want to talk about it) so I'm pretty > much stopped working on it. > > e.g. You can't say field1 = this, field2 = that, and then say compositekey > = field1,field2 you instead are forced to do key1=blah, key2=blah in all > your lookups, and no easy foreignkey properties. > > I'm running this on production environments, so it works fine, but I can up > SVN and fix any conflicts and post a patch again. > > -- > David Cramer > Director of Technology > iBegin > http://www.ibegin.com/ > > > > --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Manage.py custom commands overloading
On Thu, Oct 30, 2008 at 1:46 PM, bo <[EMAIL PROTECTED]> wrote: > so i suppose you don't consider "django" to be the "master project" > then? :) Again, as far as the code is concerned, there's no such thing as a "project" at all. Apps, sure — there's an app loader, an app cache, and eventually there'll be app objects representing installed apps. "Project" is just shorthand for "a Python module that contains some settings and perhaps some other stuff." Django itself is a Python module like everything else. It provides some apps — ``django.contrib.*`` — and a bunch of other stuff. > yes, that's what i'm doing currently, but it feels like its in the > wrong place. Explain further, perhaps? If this is just a "feeling" as you suggest, there isn't a whole lot we can do other than agree that we "feel" differently about the design of custom commands. If, on the other hand, there's something *specific* that putting a command in an app *doesn't* let you do, explain further. > to pose the question: > Why would "syncdb" sit in the App level and not the project level? > (and if you think of 'django' as the base-project it already sits at a > project level) ``syncdb`` isn't an app command. It's a built-in. > One still cannot overload the 'base' commands. Mmmm, that's not true. See, for example, South's overridding of syncdb: http://south.aeracode.org/browser/trunk/management/commands/syncdb.py. > Sure 'runserver' could be 'app' specific, but 90% of the time its > usually multi-app specific. Leaving no real options for a custom > handler. (without writing a "runMyFancyserver" command in an "app" > that's not really an app .. ). See, I think you're confusing what an app is for. The whole idea of an app is to abstract something like ``runMyFancyserver `` into a package that's reusable everywhere. I don't want to write ``runMyFancyserver`` multiple times for each site I write; I'd rather write a ``runMyFancyserver`` app and just install it on sites that need fancy servers. For a more concrete example of how this works in the real world, take a look at django-command-extensions (http://code.google.com/p/django-command-extensions/). It's a bunch of commands rolled out into an app that *just exists to provide those commands*. This is exactly correct — the only thing I'd do differently would be to actually favor each command (or each set of related commands) into a different app so I could selectively install just the few that I wanted. > Then if one 'can' overload the base command what should be the > precedence order? should 2 apps defined "runserver" who wins .. > usually the 'last guy in the load order' i would assume. This is exactly how it works right now. > Or should there be certain commands that "concat" and some that > cannot? Again, take a look at South's ``syncdb`` for an example of how this is working, already, in Django 1.0. Jacob --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
Well GenericRelation's or whatever are an attempt to provide some composite space, but we need an expandable space, not something tied to content type's. We need to say mykey = CompositeField(field, field, field) or something. No one wanted to discuss it at DjangoCon, so no. On Thu, Oct 30, 2008 at 3:57 PM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > That would be great. The project I am working on now won't be doing > anything too terribly complex just yet; I mainly need the admin support to > make my life a little easier. > > As to the API, I saw several proposals earlier along on this thread, but > obviously nothing solid. Did anything ever come from DjangoCon on this > topic? What issues still need to be addressed in this design? > > On Thu, Oct 30, 2008 at 13:46, David Cramer <[EMAIL PROTECTED]> wrote: > >> It allows you to use them, automatically creates them, and has some of the >> admin handling done. However, there's still no API design around >> multi-column fields (no one seems to want to talk about it) so I'm pretty >> much stopped working on it. >> >> e.g. You can't say field1 = this, field2 = that, and then say compositekey >> = field1,field2 you instead are forced to do key1=blah, key2=blah in all >> your lookups, and no easy foreignkey properties. >> >> I'm running this on production environments, so it works fine, but I can >> up SVN and fix any conflicts and post a patch again. >> >> -- >> David Cramer >> Director of Technology >> iBegin >> http://www.ibegin.com/ >> >> >> > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
On Thu, Oct 30, 2008 at 10:23 PM, James Bennett <[EMAIL PROTECTED]>wrote: > Except for the part where it breaks/causes headaches for eggs and > zipped packages, both of which are somewhat popular in this Python > world. There should be significantly greater number of Django projects that are deployed without any fancy stuff involved. Anyway, if someone wants to deploy his project as egg it would be easy to just change "PROJECT_DIR =.." as all other settings might stay the same. Valts. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Optional {% default %} clause for the {% for %} template tag
> {% for color in patches %}
> Bikeshed: {{ color }}
> {% default %}
> Person who writes the patch decides
> {% endfor %}
Yay, I decide! Err, decided.. :) There is a patch attached to ticket
#6398 that implements "default".
Cheers,
Jannis
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
