It would be nice mechanism to fully qualify a particular tag.so for example if I had a 'calendar' tag, and hugo also had one, and I needed to use another templatetag of his in the same file I could specify{% ian.calendar %} instead of {% calendar %} so the template would know which one I was refer
On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Next time I'm picking two Place types that have absolutely nothing in
> common so that you can't twist my examples into cases like this.
> Restaurants and SmallCometsInTheOortCloud, for example. I'm making this
> too easy for you.
Here's
On 8/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2006-08-08 at 07:35 +0800, Russell Keith-Magee wrote:
> [...]
> >
> > For those late to the discussion, it should be noted that this was one
> > of the ideas proposed for implementing inheritance. It was rejected on
> > two groun
Alan Green wrote:
> Sure. In this case you would need a discriminator attribute on Place.
[...]
> I'd be pleased to see Django require discriminator attributes on
> superclasses, and then automagically retrieve the correct subclasses
> at the correct times. It seems to work well enough in ORMs suc
On Tue, 2006-08-08 at 10:39 +1000, Malcolm Tredinnick wrote:
[...]
> This stuff is hard not because we are not very clever, but because it is
> quite possibly fundamentally hard. There is a famous comment from Bjarne
> Stroustrup where he mentioned that AT&T (his employer) had tried very
> hard to
Hey Jason,
On Mon, 2006-08-07 at 14:47 +, [EMAIL PROTECTED] wrote:
> (Bumped again, since it seems that the first message and first bump
> both got lost in the noise.)
I saw them. I just haven't got to them yet.
> Hi all multi-db wanters,
>
> The branch is now feature-complete, at least un
On Mon, 2006-08-07 at 14:22 -0400, Kevin Menard wrote:
> On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > We don't need a default solution for this. It's not within the scope
> > of this project to tell people how they should organize their settings
> > files. Take that opportunity to
On Mon, 2006-08-07 at 09:26 -0700, Bjørn Stabell wrote:
> Okay, I've got one more question. If we're not going to support
> querying for an object's real type, it becomes quite cumbersome to do
> anything polymorphically, which kind-of is the point of
> object-orientation.
This stuff is hard not
On Tue, 2006-08-08 at 07:35 +0800, Russell Keith-Magee wrote:
[...]
>
> For those late to the discussion, it should be noted that this was one
> of the ideas proposed for implementing inheritance. It was rejected on
> two grounds:
>
> 1) Lack of support for legacy databases
> 2) The number of jo
On 8/8/06, Alan Green <[EMAIL PROTECTED]> wrote:
Hi Bjørn,Sure. In this case you would need a discriminator attribute on Place.I'm thinking of code along the lines of:class Place(models.Model):...discriminator = models.CharField(maxlength=50)
def save(self):self.discriminator =
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The thing is, there's no foolproof distinction between what settings
> should differ for dev environments and which ones are definitely for
> production environments. You gave the examples of MIDDLEWARE_CLASSES
> and ROOT_URLCONF, but those
On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> Please see my message later is this thread that clarifies a bit. As
> an example, I would consider database settings to be a user-based
> setting whereas something like MIDDLEWARE_CLASSES or ROOT_URLCONF to
> be project-wide.
>
> To me it seems
Hi Bjørn,
Sure. In this case you would need a discriminator attribute on Place.
I'm thinking of code along the lines of:
class Place(models.Model):
...
discriminator = models.CharField(maxlength=50)
def save(self):
self.discriminator = self.__class__.__name__.lower()
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> > I would be all for this. I never liked that the settings file
> > contains both project-wide and user settings. Since it's
> > project-wide, it gets added to the SCM. Since it contai
On 08/07/06 20:35, Michael Radziej wrote:
> Steven Armstrong wrote:
>
>> Why not just create a second settings file, call it settings_local.py or
>> whatever, and at the end of settings.py do something like:
>>
>> from settings_local import *
>
> Well (apart from Adrian has put out his word no
On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> I would be all for this. I never liked that the settings file
> contains both project-wide and user settings. Since it's
> project-wide, it gets added to the SCM. Since it contains user
> settings, users really shouldn't commit it back. I re
Steven Armstrong wrote:
> Why not just create a second settings file, call it settings_local.py or
> whatever, and at the end of settings.py do something like:
>
> from settings_local import *
Well (apart from Adrian has put out his word now ...), my problem
was that I had to build a debian pa
On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> We don't need a default solution for this. It's not within the scope
> of this project to tell people how they should organize their settings
> files. Take that opportunity to showcase your individualism.
With the lack of an endorsed conven
On 08/07/06 19:27, limodou wrote:
> On 8/8/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> On 08/07/06 18:39, limodou wrote:
>> > On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>> >>
>> >> limodou wrote:
>> >> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> >> >> On 8/7/06, Jo
On 8/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> > Maybe more. So which one is the best, and whether it can be used in
> > django as a default solution? And whether we need a good solution? Or
> > we don't need it at all, there is no such a
On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> Maybe more. So which one is the best, and whether it can be used in
> django as a default solution? And whether we need a good solution? Or
> we don't need it at all, there is no such a default solution, you can
> do everything as long as you can fin
How to use namespace? For example,
{% load example %}
{% example.testtag %}
And I think if the namespace can be optional is better. I don't know
if it's useful, but sometimes I read others projects, and as I reading
the template, I don't know which tag is in which file. So find the
correct tag d
On 8/8/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>
> On 08/07/06 18:39, limodou wrote:
> > On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> >>
> >> limodou wrote:
> >> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> >> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
> >> >>> Would
On 08/07/06 18:39, limodou wrote:
> On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>>
>> limodou wrote:
>> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
>> >>> Wouldn't you want to put your database settings (Username and password)
>> >
"Todd O'Bryan" <[EMAIL PROTECTED]> writes:
> Yes, this will be slower than having Apache serve the file directly,
> but it has the huge advantage that the file is served as the result
> of a view. That means you can do all kinds of interesting permission
> checking, url mapping, and general
On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> limodou wrote:
> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
> >>> Wouldn't you want to put your database settings (Username and password)
> >>> in another file as well?
> >> I would b
On 8/7/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I strongly disbelieve that any fixed scheme of storing some
> settings separately will cover everybody's needs. It's easy
> enough to code your own thing in your settings.py.
You'll never cover everybody's needs, but you can cover the vast
Okay, I've got one more question. If we're not going to support
querying for an object's real type, it becomes quite cumbersome to do
anything polymorphically, which kind-of is the point of
object-orientation.
For example, to use the same URI spec & view for all the subtypes.
OPTION 1: lots of
limodou wrote:
> On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
>>> Wouldn't you want to put your database settings (Username and password)
>>> in another file as well?
>> I would be all for this. I never liked that the settings file
>> contains bo
On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>
> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
> >
> > Wouldn't you want to put your database settings (Username and password)
> > in another file as well?
>
> I would be all for this. I never liked that the settings file
> contains both project-w
(Bumped again, since it seems that the first message and first bump
both got lost in the noise.)
Hi all multi-db wanters,
The branch is now feature-complete, at least until you all get your
hands on it and start asking me to change stuff you don't like. :) (Or
agree that the implementation of mo
On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
>
> Wouldn't you want to put your database settings (Username and password)
> in another file as well?
I would be all for this. I never liked that the settings file
contains both project-wide and user settings. Since it's
project-wide, it gets added to
Hi,
this type of questions, that seems to come again and again, can
be solved for example by having an ini-style file of deployment
specific settings somewhere and reading them in your settings.py
file. An example implementation is attached, and here's an
example of how the ini file could look lik
Hi Malcolm,
First of all, I'm really sorry about the delay, I was on my
no-internet-no-cellphone vacation week, and just got your message today. I
ran all the following tests with today's SVN (r3529).
On Tuesday 01 August 2006 07:11, Malcolm Tredinnick wrote:
> 1. In the original django-users
Wouldn't you want to put your database settings (Username and password)
in another file as well?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
John Sutherland wrote:
> One thing of note is that e-mail address is not unique, however you
> could set the username to be a hash of the e-mail address as the
> username but this gets messy fast!
We (well, my django-programming colleague) have done authentication by
email address. For the use
36 matches
Mail list logo
