Gary Wilson wrote:
> So why the special cases? Should we keep the filters consistent with
> their str methods?
> title -> str.title()
I did realize an example where the title filter's implementation would
be desired. When you've got a possessive noun:
>>> Template("{{ text|title }}").render(Con
Is there a reason why the capfirst and title template filters don't
simply use the capitalize() and title() str methods?
The difference with capfirst is that it capitalizes the first character
without touching the others
>>> Template("{{ name|capfirst }}").render(Context({"name": "DOLORES"}))
'DO
On 11/14/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote:
>
> BTW, for Russ: the testing framework is amazing, it changed completely
> how I go about designing models for my own apps. Thanks for that! I'm
> looking forward to the fixtures support.
Cheers - I'm glad I could help.
As for the fixtur
Yeah. i understand. I'm using django with fastcgi, nice and easy.
thanks
Jacob Kaplan-Moss wrote:
> On 11/14/06 6:23 AM, comechao wrote:
> > Why not create a server like mongrel for Django?
>
> Go for it - we'll wait...
>
> No, seriously -- the main reason is that Django doesn't need it. Djang
adam wrote:
> I have a full-fledged Django application. I have a small function of
> this application that needs to receive partial files. I'm looking for
> direction on how best to implement this in Django (or in python in
> general).
>
> I want to create a handler that allows me to receive the
here are some issues concerning styles/layout and a couple of general
issues. some of the mentioned problems might be more important than
others - I just wanted to give a very personal list of what I´ve
noticed:
HTML/CSS:
### booleanfields are displayed different than any other fields - the
I have a full-fledged Django application. I have a small function of
this application that needs to receive partial files. I'm looking for
direction on how best to implement this in Django (or in python in
general).
I want to create a handler that allows me to receive the first 1k of
data from a
Casey Marshall wrote:
> I am faced with a situation where I really need to be able to import
> models from multiple Django projects. We have many projects that stand
> well enough alone on their own with their own supporting
> infrastructure. The projects we need to develop now need to work with
I am faced with a situation where I really need to be able to import
models from multiple Django projects. We have many projects that stand
well enough alone on their own with their own supporting
infrastructure. The projects we need to develop now need to work with
data across several of these
Am 15.11.2006 um 17:38 schrieb Adrian Holovaty:
>
> On 11/15/06, va:patrick.kranzlmueller <[EMAIL PROTECTED]>
> wrote:
>> within a change-list, there is always one item which links to the
>> change-form.
>> what about having additional links to related objects?
>>
>> change-list example:
>> ID
Thanks for explanation, Jeremy.
Regards,
Aidas Bendoraitis [aka Archatas]
On 11/15/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 11/15/06, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote:
> >
> > I am just curious, what the status of per-object-permissions branch
> > is. Today I noticed that
On 11/15/06, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote:
>
> I am just curious, what the status of per-object-permissions branch
> is. Today I noticed that the most recent revision number of that
> branch matches the revision number of trunk. Does that mean, that the
> per-object-permissions bran
I am just curious, what the status of per-object-permissions branch
is. Today I noticed that the most recent revision number of that
branch matches the revision number of trunk. Does that mean, that the
per-object-permissions branch is up to date with the trunk? What is
still missing in that branc
On 11/15/06, va:patrick.kranzlmueller <[EMAIL PROTECTED]> wrote:
> within a change-list, there is always one item which links to the
> change-form.
> what about having additional links to related objects?
>
> change-list example:
> ID (not linked)
> name (link to change-form)
> item (not linked)
>
+1 for such a possibility.
I think, you should edit somewhere around django/db/models/options.py
and django/contrib/admin.
Regards,
Aidas Bendoraitis [aka Archatas]
On 11/15/06, va:patrick.kranzlmueller <[EMAIL PROTECTED]> wrote:
>
> within a change-list, there is always one item which links
On 11/14/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 11/14/06 6:41 PM, shaunc wrote:
> > One reason (in my opinion) for an effort on a server would be to use
> > non-blocking i/o. You'd want to also use non-blocking i/o on the
> > database side as well. Has anyone thought about that fo
within a change-list, there is always one item which links to the
change-form.
what about having additional links to related objects?
change-list example:
ID (not linked)
name (link to change-form)
item (not linked)
user (link to the users change-form)
...
this could probably be achieved
17 matches
Mail list logo
