Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

[Kevin Henry]

> > Thanks, the accompanying discussion is very interesting and on point.
> > But as someone there points out, why stop at widgets?
>
> Because customizing widgets is a common request, unlike other attributes.

But customizing fields is quite common, no? I agree that it's rare
that you will want to override required, help_text, etc.—in fact,
that's exactly my point. The current syntax forces you to do so when
customizing the form just to get back to the behavior already
specified in the model. Your solution solves this problem for the
common case of customizing the widget, but the issue is just as
applicable for the common case of customizing the field.

But at this point, I'll come up with a more concrete proposal before
carrying on.

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket #7539 (ON DELETE support) in Django 1.2?

[Michael Glassford]

Michael Glassford wrote:
> 
> 
> hcarvalhoalves wrote:
>> On Aug 14, 11:48 pm, Russell Keith-Magee 
>> 
>> wrote:
>>> On Sat, Aug 15, 2009 at 8:09 AM, 
>>> hcarvalhoalves
>>>  wrote:
>>>
 On Aug 13, 9:30 am, Russell Keith-Magee 
 
 wrote:
> On Thu, Aug 13, 2009 at 12:04 AM, Michael 
> Glassford wrote:
> Secondly: I'm sensitive to the extent that 'on delete cascade' et al
> are phrased in SQL specific terms. I fully acknowledge the use case -
> what happens to a FK when the object it points to is deleted - but I
> want to make sure that we phrase it in a way that makes sense with
> non-SQL backends. Have you had any thoughts about this?
 Maybe using the UML terms to declare these associations, as it makes
 sense in an ORM environment, and is not SQL specific.
 ForeignKey(composition=True)
 Strong association -> relates to SQL's CASCADE or similar behavior on
 custom backends
 ForeignKey(aggregation=True)
 Weak association -> relates to SQL's SET_NULL or similar behavior on
 custom backends
 ForeignKey(restrict=True)
 Optional restrict to raise Exception on delete -> relates to SQL's
 RESTRICT
>>> This is an interesting idea - it's nicely object-based, and it gets
>>> around the SQL-specific terminology. However, it does introduce some
>>> nasty term-overloading with the phrase "aggregation".
>>>
>> This is UML, so anyone familiar with it understands Composition vs
>> Aggregation. It doesn't help if the person doesn't know UML, of
>> course, but I'm not just coming up with names of my own - it's an
>> industry standard. OTH, WEAK and STRONG are terms used neither by SQL
>> or UML, so I would be less in favor of using something like this.
>>
>> I only see two options: either use standard terms that appear in
>> literature (hence my idea for UML terms), or phrase it in a way that
>> makes very clear what happens. E.g.:
>>
>> ForeignKey(..., propagate_on_delete=True)
>> CASCADE
>>
>> ForeignKey(..., propagate_on_delete=False, null=False)
>> RESTRICT
>>
>> ForeignKey(..., propagate_on_delete=False, null=True)
>> SET NULL
>>
>> ForeignKey(..., propagate_on_delete=False, default=XXX)
>> SET DEFAULT
>>
>> ForeignKey(..., propagate_on_delete=False)
>> Raises Exception, need to define either "null" or "default"

Drat, my email client sent this before I was finished with it. I was 
going to say:

This eliminates the possibility of RESTRICT (not CASCADE) when null=True 
or default=xxx
are specified, which I think goes to far. I prefer either Russell 
Keith-Magee's original suggestion:

ForeignKey(XXX, association=STRONG)
   - The current arrangement, equivalent to SQL ON DELETE CASCADE

ForeignKey(XXX, association=WEAK, null=True)
   - The equivalent of SQL ON DELETE SET NULL

ForeignKey(XXX, association=WEAK, default=xxx)
   - The equivalent of SQL ON DELETE SET DEFAULT

ForeignKey(XXX, association=PROTECTED)
   - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented.

Or my original suggestion (using on_delete=CASCADE, SET_NULL, 
SET_DEFAULT, PREVENT) or a modified version of my original suggestion to 
make it more like the above by combining SET_NULL and SET_DEFAULT into a 
single SET_VALUE (which would use default if available, otherwise would 
set to None if null=True).

Drat


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket #7539 (ON DELETE support) in Django 1.2?

[Russell Keith-Magee]

On Sat, Aug 15, 2009 at 10:46 PM, Michael Glassford wrote:
>
> Russell Keith-Magee wrote:
>> On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford 
>> wrote:
>>> Russell Keith-Magee wrote:
 On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves 
 wrote:
> On Aug 13, 9:30 am, Russell Keith-Magee 
> wrote:
>> On Thu, Aug 13, 2009 at 12:04 AM, Michael 
>> Glassford wrote:
>>
>> Secondly: I'm sensitive to the extent that 'on delete cascade' et al
>> are phrased in SQL specific terms. I fully acknowledge the use case -
>> what happens to a FK when the object it points to is deleted - but I
>> want to make sure that we phrase it in a way that makes sense with
>> non-SQL backends. Have you had any thoughts about this?
> Maybe using the UML terms to declare these associations, as it makes
> sense in an ORM environment, and is not SQL specific.
>
> ForeignKey(composition=True)
> Strong association -> relates to SQL's CASCADE or similar behavior on
> custom backends
>
> ForeignKey(aggregation=True)
> Weak association -> relates to SQL's SET_NULL or similar behavior on
> custom backends
>
> ForeignKey(restrict=True)
> Optional restrict to raise Exception on delete -> relates to SQL's
> RESTRICT
 This is an interesting idea - it's nicely object-based, and it gets
 around the SQL-specific terminology. However, it does introduce some
 nasty term-overloading with the phrase "aggregation".

 However, the 'strong/weak' distinction is an interesting starting
 point for some language. A proposal:

 ForeignKey(XXX, association=STRONG)
  - The current arrangement, equivalent to SQL ON DELETE CASCADE

 ForeignKey(XXX, association=WEAK, null=True)
  - The equivalent of SQL ON DELETE SET NULL

 ForeignKey(XXX, association=WEAK, default=xxx)
  - The equivalent of SQL ON DELETE SET DEFAULT

 ForeignKey(XXX, association=PROTECTED)
  - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented.

 For completeness:

 ForeignKey(XXX, association=WEAK)

 would be an error, since the field doesn't allow NULLs, but an
 alternate default value hasn't been specified.

 Opinions?
>>> I think more people would understand the on_delete= than the
>>> association= terminology without having to look it up; but I'd have no
>>> problem implementing it this way if it's what gets decided on.
>>
>> Are you saying that a user who discovers on_delete=PREVENT in a model
>> won't need to do exactly the same thing? What does PREVENT mean? It
>> doesn't have an SQL equivalent - what is going to be prevented?
>
> True, they would have to look up PREVENT, but probably not CASCADE,
> SET_NULL, or SET_DEFAULT.
>
>> If you want to argue that association=STRONG et al is a bad conceptual
>> abstraction, thats fine. However, I won't accept the argument that
>> on_delete=CASCADE is better because it is somehow renders the user
>> immune from a need to read documentation. We _want_ users to read the
>> documentation on a feature before they use it. We _want_ to break the
>> assumptions they might bring with regard to SQL implementations.
>
> I'm not really arguing in favor of it, just mentioning that more people
> will be familiar with the on_delete concept. At this point I don't have
> a strong preference for either method over the other. I do think I would
> prefer either method to nothing at all.
>
> One more question that occurred to me this morning is, what would this do:
>
> ForeignKey(XXX, association=WEAK, null=True, default=xxx)
>   - Is this the equivalent of SET NULL or SET DEFAULT?

SET DEFAULT. The SET-equivalent options are based entirely on the
value of `default`. The `null` argument doesn't affect this feature.
SET NULL is just the special case when you (implicitly or explicitly)
have default=None. Keep in mind that:

ForeignKey(XXX)

is actually an implicit version of:

ForeignKey(XXX, default=None)

but if you have default=None, you'd better have null=True as well, or
else you're going to get validation errors (since null=False is the
implicit setting).

Yes, this does mean you can't specify a default but have FK's reset to
NULL. However, to my mind, that's what a default means. Again - we're
not trying to reproduce SQL here, we're trying to come up with an
object model that makes sense.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en

Re: Ticket #7539 (ON DELETE support) in Django 1.2?

[Michael Glassford]

Russell Keith-Magee wrote:
> On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford 
> wrote:
>> Russell Keith-Magee wrote:
>>> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves 
>>> wrote:
 On Aug 13, 9:30 am, Russell Keith-Magee 
 wrote:
> On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford 
> wrote:
>
> Secondly: I'm sensitive to the extent that 'on delete cascade' et al
> are phrased in SQL specific terms. I fully acknowledge the use case -
> what happens to a FK when the object it points to is deleted - but I
> want to make sure that we phrase it in a way that makes sense with
> non-SQL backends. Have you had any thoughts about this?
 Maybe using the UML terms to declare these associations, as it makes
 sense in an ORM environment, and is not SQL specific.

 ForeignKey(composition=True)
 Strong association -> relates to SQL's CASCADE or similar behavior on
 custom backends

 ForeignKey(aggregation=True)
 Weak association -> relates to SQL's SET_NULL or similar behavior on
 custom backends

 ForeignKey(restrict=True)
 Optional restrict to raise Exception on delete -> relates to SQL's
 RESTRICT
>>> This is an interesting idea - it's nicely object-based, and it gets
>>> around the SQL-specific terminology. However, it does introduce some
>>> nasty term-overloading with the phrase "aggregation".
>>>
>>> However, the 'strong/weak' distinction is an interesting starting
>>> point for some language. A proposal:
>>>
>>> ForeignKey(XXX, association=STRONG)
>>>  - The current arrangement, equivalent to SQL ON DELETE CASCADE
>>>
>>> ForeignKey(XXX, association=WEAK, null=True)
>>>  - The equivalent of SQL ON DELETE SET NULL
>>>
>>> ForeignKey(XXX, association=WEAK, default=xxx)
>>>  - The equivalent of SQL ON DELETE SET DEFAULT
>>>
>>> ForeignKey(XXX, association=PROTECTED)
>>>  - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented.
>>>
>>> For completeness:
>>>
>>> ForeignKey(XXX, association=WEAK)
>>>
>>> would be an error, since the field doesn't allow NULLs, but an
>>> alternate default value hasn't been specified.
>>>
>>> Opinions?
>> I think more people would understand the on_delete= than the
>> association= terminology without having to look it up; but I'd have no
>> problem implementing it this way if it's what gets decided on.
> 
> Are you saying that a user who discovers on_delete=PREVENT in a model
> won't need to do exactly the same thing? What does PREVENT mean? It
> doesn't have an SQL equivalent - what is going to be prevented?

True, they would have to look up PREVENT, but probably not CASCADE, 
SET_NULL, or SET_DEFAULT.

> If you want to argue that association=STRONG et al is a bad conceptual
> abstraction, thats fine. However, I won't accept the argument that
> on_delete=CASCADE is better because it is somehow renders the user
> immune from a need to read documentation. We _want_ users to read the
> documentation on a feature before they use it. We _want_ to break the
> assumptions they might bring with regard to SQL implementations.

I'm not really arguing in favor of it, just mentioning that more people 
will be familiar with the on_delete concept. At this point I don't have 
a strong preference for either method over the other. I do think I would 
prefer either method to nothing at all.

One more question that occurred to me this morning is, what would this do:

ForeignKey(XXX, association=WEAK, null=True, default=xxx)
   - Is this the equivalent of SET NULL or SET DEFAULT?

>> How would the equivalent of ON UPDATE be handled in this type of scheme,
>> assuming it gets added at some point?
> 
> What aspect of ON UPDATE are you looking to implement? It isn't
> immediately obvious to me that ON UPDATE is a good idea, or one that
> has a natural object-based interpretation.

I agree that it's less important and less obviously useful than ON 
DELETE. I'll see if I can come up with a more compelling example, but 
the way we've mainly used it is to set a lot of our foreign keys to 
on_update=CASCADE. This is because the default SQL behavior when no ON 
UPDATE clause is specified is to RESTRICT.

Mike


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: admin reuse

[Julien Phalip]

On Aug 15, 9:14 pm, Russell Keith-Magee 
wrote:
> On Sat, Aug 15, 2009 at 3:52 PM, Haroldo
>
> Stenger wrote:
> >  I've seen the admin evolve to very sophisticated user interaction.
> > Nonetheless, the param to  HttpResponse() when a model object has been
> > saved, is hardcoded and most of the times "../../.." or "../.."  (see
> > options.py in contrib.admin).
>
> This is a historical artefact. As of v1.1, the 'right way' to do this
> would be to use a named URL pattern. Some of the usages of '../..'
> paths have been corrected, but there are still some remaining. It
> doesn't harm anything while they remain, but I expect that they will
> eventually get cleaned up.
>
> > Being able to change that string by some means
> > of instantiation or runtime configuration, could allow a view to use the
> > admin to edit an object, and once the model object has been saved modified,
> > automatically return to the view (or another view registered in URLconf). I
> > wonder if this has ben thought before, and if there would be much resistance
> > to a change in that HttpResponse's parameter flexibility.
>
> I'm not sure I see why this parameter needs to be configurable. When
> you save an object, it goes back to the list of objects of the same
> type. I can't think of any other logical place for the view to
> redirect.
>
> It sounds like you're trying to use the admin edit views within your
> own application. If this is the case, let me advise you that Django's
> admin isn't intended as a way to avoid writing edit views for your own
> site. If you want to edit objects in your own site, just write write
> edit views - it isn't that hard to use a modelform.
>
> If you have another use case, I'd be interested to hear it.
>
> Yours,
> Russ Magee %-)

About a year ago (pre-Django 1.0) I had posted a ticket with a similar
request: http://code.djangoproject.com/ticket/8001

I agree that the redirection shouldn't be hardcoded. This is
inconsistent because some views allow for customisation (with the
'post_url_continue' parameter) but other views don't.

Haroldo, maybe the posted patch would be a good starting point for
your problem?

Russ, one use case that I've had is with a menu app. I wanted to have
an integrated way to manage items in a menu, for example with the
following URLs:
http://blah.com/admin/menus/menu/1/additem/
http://blah.com/admin/menus/menu/1/items/3/

To edit/add items, I used an unregistered ModelAdmin class to benefit
from all the admin machinery. It worked fine except that the default
hardcoded redirection didn't allow for it, so I had to overwrite some
bits in the views. Not a huge deal, but it's one of those little
customisation hooks that make life easier ;)

Cheers,

Julien
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket #7539 (ON DELETE support) in Django 1.2?

[Russell Keith-Magee]

On Sat, Aug 15, 2009 at 10:57 AM, Michael Glassford wrote:
>
> Russell Keith-Magee wrote:
>> On Sat, Aug 15, 2009 at 8:09 AM, hcarvalhoalves 
>> wrote:
>>> On Aug 13, 9:30 am, Russell Keith-Magee 
>>> wrote:
 On Thu, Aug 13, 2009 at 12:04 AM, Michael Glassford 
 wrote:

 Secondly: I'm sensitive to the extent that 'on delete cascade' et al
 are phrased in SQL specific terms. I fully acknowledge the use case -
 what happens to a FK when the object it points to is deleted - but I
 want to make sure that we phrase it in a way that makes sense with
 non-SQL backends. Have you had any thoughts about this?
>>> Maybe using the UML terms to declare these associations, as it makes
>>> sense in an ORM environment, and is not SQL specific.
>>>
>>> ForeignKey(composition=True)
>>> Strong association -> relates to SQL's CASCADE or similar behavior on
>>> custom backends
>>>
>>> ForeignKey(aggregation=True)
>>> Weak association -> relates to SQL's SET_NULL or similar behavior on
>>> custom backends
>>>
>>> ForeignKey(restrict=True)
>>> Optional restrict to raise Exception on delete -> relates to SQL's
>>> RESTRICT
>>
>> This is an interesting idea - it's nicely object-based, and it gets
>> around the SQL-specific terminology. However, it does introduce some
>> nasty term-overloading with the phrase "aggregation".
>>
>> However, the 'strong/weak' distinction is an interesting starting
>> point for some language. A proposal:
>>
>> ForeignKey(XXX, association=STRONG)
>>  - The current arrangement, equivalent to SQL ON DELETE CASCADE
>>
>> ForeignKey(XXX, association=WEAK, null=True)
>>  - The equivalent of SQL ON DELETE SET NULL
>>
>> ForeignKey(XXX, association=WEAK, default=xxx)
>>  - The equivalent of SQL ON DELETE SET DEFAULT
>>
>> ForeignKey(XXX, association=PROTECTED)
>>  - The equivalent of SQL ON DELETE RESTRICT. Deletion is prevented.
>>
>> For completeness:
>>
>> ForeignKey(XXX, association=WEAK)
>>
>> would be an error, since the field doesn't allow NULLs, but an
>> alternate default value hasn't been specified.
>>
>> Opinions?
>
> I think more people would understand the on_delete= than the
> association= terminology without having to look it up; but I'd have no
> problem implementing it this way if it's what gets decided on.

Are you saying that a user who discovers on_delete=PREVENT in a model
won't need to do exactly the same thing? What does PREVENT mean? It
doesn't have an SQL equivalent - what is going to be prevented?

If you want to argue that association=STRONG et al is a bad conceptual
abstraction, thats fine. However, I won't accept the argument that
on_delete=CASCADE is better because it is somehow renders the user
immune from a need to read documentation. We _want_ users to read the
documentation on a feature before they use it. We _want_ to break the
assumptions they might bring with regard to SQL implementations.

> How would the equivalent of ON UPDATE be handled in this type of scheme,
> assuming it gets added at some point?

What aspect of ON UPDATE are you looking to implement? It isn't
immediately obvious to me that ON UPDATE is a good idea, or one that
has a natural object-based interpretation.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: admin reuse

[Russell Keith-Magee]

On Sat, Aug 15, 2009 at 3:52 PM, Haroldo
Stenger wrote:
>  I've seen the admin evolve to very sophisticated user interaction.
> Nonetheless, the param to  HttpResponse() when a model object has been
> saved, is hardcoded and most of the times "../../.." or "../.."  (see
> options.py in contrib.admin).

This is a historical artefact. As of v1.1, the 'right way' to do this
would be to use a named URL pattern. Some of the usages of '../..'
paths have been corrected, but there are still some remaining. It
doesn't harm anything while they remain, but I expect that they will
eventually get cleaned up.

> Being able to change that string by some means
> of instantiation or runtime configuration, could allow a view to use the
> admin to edit an object, and once the model object has been saved modified,
> automatically return to the view (or another view registered in URLconf). I
> wonder if this has ben thought before, and if there would be much resistance
> to a change in that HttpResponse's parameter flexibility.

I'm not sure I see why this parameter needs to be configurable. When
you save an object, it goes back to the list of objects of the same
type. I can't think of any other logical place for the view to
redirect.

It sounds like you're trying to use the admin edit views within your
own application. If this is the case, let me advise you that Django's
admin isn't intended as a way to avoid writing edit views for your own
site. If you want to edit objects in your own site, just write write
edit views - it isn't that hard to use a modelform.

If you have another use case, I'd be interested to hear it.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django settings paths mess

[Graham Dumpleton]

On Aug 15, 6:42 pm, Yuri Baburov  wrote:
> On Sat, Aug 15, 2009 at 12:24 PM, Graham
>
>
>
>
>
> Dumpleton wrote:
> > On Aug 15, 1:15 pm, Yuri Baburov  wrote:
> >> Hi all,
>
> >> I'm trying to figure out correct overall and settings path usage
> >> strategy for my Django applications.
> >> What I am experiencing now is that settings.py is imported 4 times on
> >> "python manage.py runserver" command,
> >> twice as "settings", and twice as "myapp.settings", given that my
> >> project is named "myapp".
> >> It also doesn't care if I set DJANGO_SETTINGS_MODULE env option and
> >> PYTHONPATH env option.
>
> >> My desire is to make it use "settings", and don't ever use project
> >> prefix "myapp."
>
> > Personally I believe that eliminating the project prefix is a bad
> > idea. By doing that you start to push to much stuff into global module
> > namespace and too much change of a conflict.
>
> Maybe let's rename all apps to UUIDs then? :)
> I have never experienced namespace conflicts you are talking about.
> Chance of conflict is almost zero.
> You underestimate python import agility.

You underestimate stupid users. I have seen many times where users
stuff up because they do something like call a script file django.py
or test.py and wander why the latter standard packages/modules of same
name can't seem to be found, or why their own code isn't found. There
are lots of other standard modules in Python which one can conflict
with as well because of use of quite generic names.

> Only global modules get into global modules namespace, app modules get
> into app namespaces.

You said that your 'desire is to make it use "settings" , and don't
ever use project prefix "myapp."'. To do that, it means that
'settings' has been promoted to global modules namespace.

Django runserver is a pain in that it effectively allows this by
default, and in part why you are seeing the problem you are having in
the first place.

That is, it may add sys.path temporarily to import site package root
into sys.modules so that 'site.settings' works, but the current
working directory of the runserver is the actual site directory. This
means importing 'settings' works as well. That is, 'settings.py' is
importable as both sub module of site package, but as global module in
it is own right. Thus why it can be imported twice. If the runserver
had been implemented to change to a different directory, it would get
rid of this problem and also get rid of the problem where people use
relative path names for stuff which may work for runserver but then
doesn't work when they move to hosting with mod_python, mod_wsgi, or
fastcgi.

> Local modules are checked before global ones. If you will load "q"
> from "w", it will be imported as "q.w" into sys.modules
> Say, realapp1 can have module models.py and can be accessed as
> "models" from inside and "realapp1.models" from outside. Local modules
> will be checked before global from inside, and no name conflict will
> ever arise.
> But most times internal "models" are also accessed as
> "realapp1.models", of course.
> This will work until you will use app as sub-app of some other app
> (say, I want to use django-filter as beautils/filter/ and it will not
> work because it uses filter.* form of imports). Such reuse will be
> possible only with local imports imports.> What I would suggest is 
> experimenting with standardising on one prefix
> > and having everything internally reference via that no matter what the
> > project directory is called. You can then set up a dummy module as
> > entry point.
>
> It's just very bad idea to have 2 apps with the same name, but single
> global namespace won't help it!
> Be it project name, or "djangosite".

You possibly don't fully understand why I am suggesting this and how
it would be of use. Maybe the problem is that you are after something
other than the problem I perceive you are trying to solve. You perhaps
also haven't encountered as many times the issues around this double
import and fact that imports can be done without listing site package
root at same time as I have in answering Django questions on the lists
over the years. It is one part of Django I would really like to have
seen be done differently because of the grief it keeps causing people
who want to host with mod_python and mod_wsgi.

FWIW, having all sites use the same logical package root name wouldn't
cause any harm because for Django, it is impossible to host multiple
Django site instances within the same Python interpreter. Thus there
can be no conflict. Some other Python web frameworks also get away
with always effectively having site package root be same name, because
they, like Django can only have one instance in a Python interpreter.
Thus the concept works albeit the means they do it may be different.

One of the problems it would solve is where people leave off the site
package root name because they want the ability to 

Re: App Engine support

[Waldemar Kornewald]

Hi Malcolm,
first of all, we'll soon start with a few experiments and since you
wanted to play around with some code, too, could you please tell us
your bitbucket username, so we can give you write access to the
repository?

On Aug 11, 4:07 am, Malcolm Tredinnick 
wrote:
> Things like a ListField aren't required. They could easily enough be
> done as a standard custom field, but support for every field that's
> possible in a particular database backend isn't our goal at the moment
> and we don't add stuff to Django for that reason. Django runs on
> app-engine would mean that existing applications run with the existing
> field types. Not that every possible app-engine storage structure is
> emulated in Django.

ListField is a critical data type in non-relational DBs. There needs
to be a standard that works across all non-relational backends and
that makes it possible to switch back to an SQL-backed Django. How do
you want to solve that without integrating ListField into Django?

> Batch delete() is already pretty much what happens. Batch updates
> already exist and batch saving is an often enough requested feature that
> it's likely to happen in the near future (I can imagine what an API for
> that might look like, for example).

Unless I've misunderstood something, there's a problem with the
current batch-delete/update operations: You can't pass existing model
instances, but only PKs. In the worst case, all rows have to be re-
fetched from the DB and the models must be re-instantiated - just to
send signals. This could be a costly operation on non-SQL DBs, so if
one already has a list of instances he wants to delete they should be
reused.

Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: overriding queryset for admin inlines

[Zachary Voase]

...would get via the actual Python API? In this case, you couldn’t
switch the managers around either.

On Aug 15, 10:19 am, Zachary Voase 
wrote:
> Correct me if I’m wrong, but won’t the inlines display the actual
> relationship that you
>
> On Aug 14, 5:43 pm, smcoll  wrote:
>
>
>
> > Currently, we can override the queryset used by ModelAdmins.  This is
> > helpful, since often times the default manager omits instances that
> > nevertheless belong in the admin.  It seems to me that there's no way
> > to override the queryset for inlines, though.  Is that correct?
> > Inlines seem to use the default manager by design, and this is another
> > expression of the same problem.
>
> > i came across this when i couldn't find my child model instances as
> > inlines in the admin; the default manager for the child model was set
> > to only show objects for the current site, and i was using the admin
> > for several sites.
>
> > i had posted about this earlier at django-users (http://
> > groups.google.com/group/django-users/browse_thread/thread/
> > 22781505121558dc/5d6a9595770afb99#5d6a9595770afb99), but now i'm
> > thinking this has to do with the way the admin contrib app is set up.
>
> > Here's a quick app i wrote to demonstrate the issue, with an attempted
> > workaround (which gets the instances to show up but doesn't allow a
> > save):http://dpaste.com/80185/
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: overriding queryset for admin inlines

[Zachary Voase]

Correct me if I’m wrong, but won’t the inlines display the actual
relationship that you

On Aug 14, 5:43 pm, smcoll  wrote:
> Currently, we can override the queryset used by ModelAdmins.  This is
> helpful, since often times the default manager omits instances that
> nevertheless belong in the admin.  It seems to me that there's no way
> to override the queryset for inlines, though.  Is that correct?
> Inlines seem to use the default manager by design, and this is another
> expression of the same problem.
>
> i came across this when i couldn't find my child model instances as
> inlines in the admin; the default manager for the child model was set
> to only show objects for the current site, and i was using the admin
> for several sites.
>
> i had posted about this earlier at django-users (http://
> groups.google.com/group/django-users/browse_thread/thread/
> 22781505121558dc/5d6a9595770afb99#5d6a9595770afb99), but now i'm
> thinking this has to do with the way the admin contrib app is set up.
>
> Here's a quick app i wrote to demonstrate the issue, with an attempted
> workaround (which gets the instances to show up but doesn't allow a
> save):http://dpaste.com/80185/
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

[Kevin Henry]

> Please file a ticket for the documentation fix it would be greatly  
> appreciated. :-)

Will do.

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

[Kevin Henry]

In terms of backward compatibility, perhaps there could be a new
keyword argument to Field, something like with_model_defaults, that
the user would use to indicate a desire to get the attributes from the
Model. How would this work? Maybe something like this (this is just a
sketch): Field.__init__() works the same way, except that it also
stores the value of the keyword arguments (with_model_defaults, as
well as the others, since the user should be able to override
individual settings). Then ModelForm's metaclass will call a method on
the field, passing in the field name. The field can then extract the
default values from the Model and set itself up appropriately.

Too much trickery? Before looking into how Django works I would have
definitely said yes, but now my standards have changed. :) (That's not
a criticism, I'm very happy with the trickery Django implies to make
life easier for the user.)


> There's also a ticket waiting for check-in implementing this common
> usecase:http://code.djangoproject.com/ticket/9223

Thanks, the accompanying discussion is very interesting and on point.
But as someone there points out, why stop at widgets? The discussion
strengthens my intuition that widgets, fields, and the attributes I'm
discussing here are fairly orthogonal concepts, and the current all-or-
nothing declarative syntax couples them too tightly. Both your
solution and the (much less thought-out) one I just proposed feel too
small to me, but I'm not sure of a better solution.

Cheers,
Kevin

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django settings paths mess

[Yuri Baburov]

On Sat, Aug 15, 2009 at 12:24 PM, Graham
Dumpleton wrote:
> On Aug 15, 1:15 pm, Yuri Baburov  wrote:
>> Hi all,
>>
>> I'm trying to figure out correct overall and settings path usage
>> strategy for my Django applications.
>> What I am experiencing now is that settings.py is imported 4 times on
>> "python manage.py runserver" command,
>> twice as "settings", and twice as "myapp.settings", given that my
>> project is named "myapp".
>> It also doesn't care if I set DJANGO_SETTINGS_MODULE env option and
>> PYTHONPATH env option.
>>
>> My desire is to make it use "settings", and don't ever use project
>> prefix "myapp."
>
> Personally I believe that eliminating the project prefix is a bad
> idea. By doing that you start to push to much stuff into global module
> namespace and too much change of a conflict.

Maybe let's rename all apps to UUIDs then? :)
I have never experienced namespace conflicts you are talking about.
Chance of conflict is almost zero.
You underestimate python import agility.
Only global modules get into global modules namespace, app modules get
into app namespaces.
Local modules are checked before global ones. If you will load "q"
from "w", it will be imported as "q.w" into sys.modules
Say, realapp1 can have module models.py and can be accessed as
"models" from inside and "realapp1.models" from outside. Local modules
will be checked before global from inside, and no name conflict will
ever arise.
But most times internal "models" are also accessed as
"realapp1.models", of course.
This will work until you will use app as sub-app of some other app
(say, I want to use django-filter as beautils/filter/ and it will not
work because it uses filter.* form of imports). Such reuse will be
possible only with local imports imports.
> What I would suggest is experimenting with standardising on one prefix
> and having everything internally reference via that no matter what the
> project directory is called. You can then set up a dummy module as
> entry point.
It's just very bad idea to have 2 apps with the same name, but single
global namespace won't help it!
Be it project name, or "djangosite".

I also use few more techniques:
I could use "apps/" folder to put my project-specific apps inside if i
wanted to. Apps will get names like "apps.somename". I tried, for IDE
to show in better way, but it wasn't really needed :)

And I symlink apps I need into my project directory.
Typical folder structure in my projects:
~django/ -> ../django-trunk/django
~beautils/ -> ../beautils
realapp1/
templates/
media/
media/~admin/ -> ../django-trunk/django/contrib/admin/media
media/~beautils/ -> ../beautils/media/beautils
media/~realapp1/ -> ../realapp1/media
settings.py
urls.py

I include only apps i needed, maybe that's the reason I don't
experience conflicts.
Two conflicts I've got within a year of work with django were "blog"
app with "blog" project and "utils" app with "utils" module, because I
left utils.pyc when removed utils.py. I can do nothing with second,
but first required a hour to find, and not only me, but my friend once
also get the exactly same problem and would also spent a lot of time
to find it if he didn't ask me :)

Will manage.py startapp raise an error if a project has the same name
as application? Will python manage.py validate do so?

And installing django modules into python environment I believe is a bad thing,
mainly because different projects might use different versions of applications.

I apply the following general rule here:
You should be able to update a library or application in one project,
not breaking others.

>> Because this will cause much greater app reusability in different
>> projects, because of "blog" project and "blog" application possible
>> import clashes (and weird errors from urlconf loader), because I want
>> to be able to rename project at any moment, because i want "111" or
>> "project-v1.1" to be also correct project folders. This is my general
>> rule: my apps shouldn't start with project prefix.
>
> So for your example, do the following:
>
>  import imp
>  import sys
>  import os
>
>  djangosite = imp.new_module('djangosite')
>  djangosite.__path__ = [ '/some/path/projects/projects-v1.1' ]
>  djangosite.__file__ = '/some/path/projects/projects-v1.1/
> __init__.py'
>
>  sys.modules['djangosite'] = djangosite
>
>  os.environ['DJANGO_SETTINGS_MODULE'] = 'djangosite.settings'
>
> Doing this also means you do not even need the parent projects
> directory in sys.path, which is effectively what runserver does as it
> adds it only long enough to import the __init__.py file as package
> root and then removes the directory.
>
> Anyway, within urls.py and all your code you could then always perform
> import references as 'djangosite.etc.etc'. With it standardised, then
> quite easy to move stuff between site implementations or rename site
> directory and not have to change everything in it.
And as I explained above, this is not 

admin reuse

[Haroldo Stenger]

 I've seen the admin evolve to very sophisticated user interaction.
Nonetheless, the param to  HttpResponse() when a model object has been
saved, is hardcoded and most of the times "../../.." or "../.."  (see
options.py in contrib.admin). Being able to change that string by some means
of instantiation or runtime configuration, could allow a view to use the
admin to edit an object, and once the model object has been saved modified,
automatically return to the view (or another view registered in URLconf). I
wonder if this has ben thought before, and if there would be much resistance
to a change in that HttpResponse's parameter flexibility.

Haroldo

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---