> {% 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
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
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
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
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
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
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
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
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
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
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,
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"
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
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
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
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
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
{% 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,
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/
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
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 :)
--
+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 %}.
>
> >
>
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
On Thu, Oct 30, 2008 at 3:05 PM, ravirocks <[EMAIL PROTECTED]> wrote:
>
> Hey guys,
>
> May be this is easy for you. I am newbie to fixtures and Django unit
> tests. My problem is the named fixture is not being loaded. The
> fixture events_2.json in the code below is being ignored. Don't know
>
Hey guys,
May be this is easy for you. I am newbie to fixtures and Django unit
tests. My problem is the named fixture is not being loaded. The
fixture events_2.json in the code below is being ignored. Don't know
why? The only thing manage.py tests events loads is initial_data.json.
Can we not
25 matches
Mail list logo
