two comments on Django

[mike45]

Hi,

I just came across Django a few days ago and found it quite
interesting. There are a few things I'd like to note:

1: I followed the tutorial and set up the poll app. After adding
several polls and choices via the admin page, that page showed the
'recent actions' list of links. Clicking on the links pointing to
edited polls worked, whereas those for edited choices didn't. The urls
that failed looked like

http://localhost:8000/admin/polls/choices/3/

whereas, indeed, after including the foreign key field into the choice
model definition, the choices had been entered through the poll pages,

http://localhost:8000/admin/polls/polls/4/

So I assume that the urls for the recent actions are generated from the
models without taking into account the effect of foreign keys.

2 This one is more substantial:

In the model definitions, aren't the field types a bit heterogeneous?
Many of them correspond to common database field types, which of course
feels right when building models for a database backend. However,
things such as EmailField, XMLField, FileField and ImageField are
different - they represent data + associated validation schemes,
blurring the distinction between model and user interface. You will
wind up with



No. of field types=SQL field types * HTML form field types * data
formats



Seriously, if you want to prevent the field types from growing into
something unwieldy like the DocBook DTD (which has some 400 recognized
tags by now), you must not include application domain-specific
conveniences at this level. I think something like

email = meta.CharField(maxLength=50,
validator=validators.Email(check='DNS'))

image = meta.CharField(maxLength=100,
validator=validators.Image(types=['eps','png']))

would be better. If required (FileField or similar), the representation
in the standard admin UI could also be defined in the Validator class.
In this way, proliferation of field types would be limited, and if we
want to change the validation procedure or the standard UI
representation we still can be sure that the underlying database field
type will stay the same.


I once tried to sanitize a database in a clinical microbiology
department. The original classification of clinical samples had had two
fields:
- origin (anatomical region)
- type of sample (swab, tissue sample, ...)
Now, the original choices in these fields had probably been taken from
some medical self-help guide and proven insufficient, and as a
consequence the users were given free reign to add choices to both
fields. This led immediately to one-field shortcuts such as 'swab
foot', 'swab foot left', 'pus buttock left', 'ham', 'honey', scattered
randomly across both fields. When the lists had grown too long to look
up, people found it more convenient to add variations on the same
entries over and over again...
I had a good laugh but never finished that job - the db was beyond
repair.


Best, Michael

Mod_python error: "PythonHandler django.core.handlers.modpython"

[moberley]

I tried to set-up a django project using mod_python on Apache/1.3.33
and I can only get mod_python error messages. The admin part displays
the following traceback (it works fine with django-admin.py runserver):

-

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 193, in Dispatch
result = object(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 164, in handler
return ModPythonHandler()(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 139, in __call__
response = self.get_response(req.uri, request)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
line 50, in get_response
response = middleware_method(request)

  File
"/usr/local/lib/python2.4/site-packages/django/middleware/sessions.py",
line 56, in process_request
request.session =
SessionWrapper(request.COOKIES.get(SESSION_COOKIE_NAME, None))

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 53, in _get_cookies
self._cookies =
httpwrappers.parse_cookie(self._req.headers_in.get('cookie', ''))

AttributeError: get

-

The regular side displays a different traceback (this also works with
django-admin.py).

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 193, in Dispatch
result = object(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 164, in handler
return ModPythonHandler()(req)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 139, in __call__
response = self.get_response(req.uri, request)

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
line 50, in get_response
response = middleware_method(request)

  File
"/usr/local/lib/python2.4/site-packages/django/middleware/common.py",
line 33, in process_request
if request.META.has_key('HTTP_USER_AGENT'):

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/modpython.py",
line 67, in _get_meta
self._meta = {

  File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py",
line 85, in __getattr__
raise AttributeError, attr

AttributeError: ap_auth_type

Re: Mod_python error: "PythonHandler django.core.handlers.modpython"

[moberley]

Sorry, I seem to have forgotten to close my message properly.

I've tried searching for information about this, but I was unable to
find anything obvious and it's a little bit beyond my knowledge of
Apache. Does anyone have any ideas what I might try to make this work?

Thanks,
Bradley Peters

Re: Table-less model as base class?

[Eric Walstad]

Adrian Holovaty wrote:
> On 9/18/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
[...]
> > Is it possible to do what I want, move common fields to a super class,
> > without generating a table for that super class?
>
> It's not currently possible, but that exact functionality is on the
> to-do list: http://code.djangoproject.com/ticket/419 .
>
> Adrian

Hi Adrian,
I'm short on time, but I think I may have hacked up something that
works (for me) and passes the unit tests.

Eric.

[EMAIL PROTECTED] django_src]$ diff -u
django/core/meta/__init__.py.orig django/core/meta/__init__.py
--- django/core/meta/__init__.py.orig   2005-09-18 14:51:18.0
-0700
+++ django/core/meta/__init__.py2005-09-18 15:59:20.0
-0700
@@ -412,6 +412,11 @@
 # attribute order.
 fields.sort(lambda x, y: x.creation_counter -
y.creation_counter)

+# Should this class generate database tables (Default is Yes)?
+# This has the ultimate effect of keeping this class out of
the _MODELS
+# list.
+create_table = not (meta_attrs.pop('no_table', False))
+
 # If this model is a subclass of another model, create an
Options
 # object by first copying the base class's _meta and then
updating it
 # with the overrides from this class.
@@ -673,7 +678,9 @@
 # contain this list:
 # [, ]
 # Don't do this if replaces_module is set.
-app_package.__dict__.setdefault('_MODELS',
[]).append(new_class)
+# Exclude models where the user has set 'no_table = True'
+if create_table:
+app_package.__dict__.setdefault('_MODELS',
[]).append(new_class)

 # Cache the app label.
 opts.app_label = app_label
@@ -725,6 +732,7 @@
 def __repr__(self):
 return '<%s object>' % self.__class__.__name__

+
 
 # HELPER FUNCTIONS (CURRIED MODEL METHODS) #
 
[EMAIL PROTECTED] django_src]$ python tests/runtests.py
Running tests with database 'postgresql'
All tests passed.


experiment.py file:
from django.core import meta

class MyBaseClass(meta.Model):
"""This class will not result in any tables being generated by
django"""
created_on = meta.DateTimeField(auto_now_add=True)
modified_on = meta.DateTimeField(auto_now=True)
class META:
no_table = True

class MyDerived(MyBaseClass):
"""This class will have tables generated and will include the:
 - created_on and
 - modified_on fields
which are inherited from the 'MyBaseClass' class.
"""
name = meta.CharField(maxlength=25)
class META:
   module_name = 'my_derived_class'

class MyOtherDerived(MyDerived):
"""This class will not result in any tables being generated by
django and
it will include all the fields inherited from both 'MyBaseClass'
and
'MyDerived' as well as those fields defined here.
"""
color = meta.CharField(maxlength=25)
class META:
module_name = 'my_other_derived'
# Explicitly set the no_table flag so that this class doesn't
result in
# a table being created.
no_table = True

class MyLastDerived(MyOtherDerived):
"""This class will have tables generated and will include the:
 - created_on and
 - modified_on fields
which are inherited from the 'MyBaseClass' class,
 - name
which is inherited from the 'MyDerived' class and
 - color
which is inherited from the 'MyOtherDerived' class as well as those
fields
defined here.
"""
size = meta.IntegerField(choices=((0, 'small'),
  (1, 'medium'),
  (2, 'large'),
  ))
class META:
module_name = 'my_last_derived'


[EMAIL PROTECTED] django_src]$ django-admin.py sql experiment
BEGIN;
CREATE TABLE experiment_my_derived_class (
id serial NOT NULL PRIMARY KEY,
modified_on timestamp with time zone NOT NULL,
created_on timestamp with time zone NOT NULL,
name varchar(25) NOT NULL
);
CREATE TABLE experiment_my_last_derived (
id serial NOT NULL PRIMARY KEY,
color varchar(25) NOT NULL,
modified_on timestamp with time zone NOT NULL,
created_on timestamp with time zone NOT NULL,
name varchar(25) NOT NULL,
size integer NOT NULL
);

Re: TurboGears

[Samat Jain]

On Sunday 18 September 2005 03:55 am, Andreas wrote:
> I just discovered TurboGears, another MVC web development framework
> based on Python (turbogears.org). Judging from the 20-Minute-Demo-Video
> it seems to be quite similar to Django, although lacking the slick
> admin interface. What do you think about it? How does it compare to
> Django?

They appear to be much more focused on using existing projects rather than 
writing their own.

For example, for an ORM they use SQLobject, compared to Django which has it's 
own. I personally like SQLobject, especially the way it handles inheritance, 
which is different (and "better" for some of the ideas I've in mind) than in 
Django.

Samat

-- 
Samat Jain 

Advertising is a valuable economic factor because it is the cheapest way of 
selling goods, particularly if the goods are worthless.
-- Sinclair Lewis (416)

Re: Table-less model as base class?

[Robert Wittams]

Adrian Holovaty wrote:
> On 9/18/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
> 
>>I'd like to make a base class for my model classes that defines some
>>fields but doesn't result in a table in the database.  If my base class
>>is derived from meta.Model, then django makes a table for it in the
>>database.
>>
>>Is it possible to do what I want, move common fields to a super class,
>>without generating a table for that super class?
> 
> 
> It's not currently possible, but that exact functionality is on the
> to-do list: http://code.djangoproject.com/ticket/419 .
> 
> Adrian
> 

Is it possible or planned to make the generated methods for superclasses
aggregate sub class instances?

Eg

class animal(meta.Model):
name = TextField()

class dog(animal):
   pass

class cat(animal):
   pass


Then animal.get_list(name__exact='Fluff') would return instances of both
cats and dogs.

As far as I can tell this doesn't currently work.

RE: New Free Downloads

[scottpierce]

I have reported this as spam.

Scott Pierce

Re: Table-less model as base class?

[Adrian Holovaty]

On 9/18/05, Eric Walstad <[EMAIL PROTECTED]> wrote:
> I'd like to make a base class for my model classes that defines some
> fields but doesn't result in a table in the database.  If my base class
> is derived from meta.Model, then django makes a table for it in the
> database.
> 
> Is it possible to do what I want, move common fields to a super class,
> without generating a table for that super class?

It's not currently possible, but that exact functionality is on the
to-do list: http://code.djangoproject.com/ticket/419 .

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

Table-less model as base class?

[Eric Walstad]

Hi all,

I'd like to make a base class for my model classes that defines some
fields but doesn't result in a table in the database.  If my base class
is derived from meta.Model, then django makes a table for it in the
database.

Is it possible to do what I want, move common fields to a super class,
without generating a table for that super class?

Thanks,

Eric.

contrived example follows (I don't want the 'experiment_mybaseclasss'
table created):

experiment/models/experiment.py:
from django.core import meta
class myBaseClass(meta.Model):
created_on = meta.DateTimeField(auto_now_add=True)
modified_on = meta.DateTimeField(auto_now=True)
class myDerivedClass(myBaseClass):
name = meta.CharField(maxlength=25)
class META:
   module_name = 'my_derived_class'


$ django-admin.py sql experiment
BEGIN;
CREATE TABLE experiment_mybaseclasss (
id serial NOT NULL PRIMARY KEY,
created_on timestamp with time zone NOT NULL,
modified_on timestamp with time zone NOT NULL
);
CREATE TABLE experiment_my_derived_class (
id serial NOT NULL PRIMARY KEY,
modified_on timestamp with time zone NOT NULL,
created_on timestamp with time zone NOT NULL,
name varchar(25) NOT NULL
);
COMMIT;

Re: befuddled with formfields.py

[scottpierce]

I don't know that I would call it hacking around.  Yes.  There seems to
be a lot of stuff within the admin that is not exposed outside of the
admin.  Manipulators will act accordingly if given formfieldcollections
for "inline" tables; however, they aren't exposed outside the admin as
they should or could be.  I have been working on some stuff to expose
this functionality and have it working but it isn't ready for prime
time.

Circular model references (was: Help me checking this model)

[Eric Walstad]

Brant Harris wrote:
> > How would this model be implemented in Django? The API provides a
> > special case where a recursive relationship back to the current
entity
> > is denoted by ForeignKey('self'), but for the more general case of
a
> > circular relationship I can't see a way to avoid the NameError.
> >
> > I know in SqlObject the class's name can be used instead of a
> > reference to the class, providing late binding to enable this kind
of
> > model.
>
> There is no current way of doing this.  Perhaps some of the main
> developers for Django could extrapolate further on this, but I
believe
> the idea is partially to restrict such "circular" relationships as
> they are considered poor database/model design.


Are these still considered poor database/model design?

Here's my situation:
My 'Person' objects have zero or more 'Locations'.
Locations have 'created_by' and 'modified_by' references to the
'Person' table.

The following abreviated model definitions cause 'django-admin.py
install' to fail:

class Location(meta.Model):
address = meta.CharField(maxlength=255)
# ...
created_by = meta.ForeignKey(Person)
mod_by = meta.ForeignKey(Person)


class Person(meta.Model):
primary_address = \
meta.ForeignKey(Location)
fn = meta.CharField('first name', maxlength=255)
ln = meta.CharField('last name', maxlength=255)
# ...
created_by = meta.ForeignKey('self',
 related_name='creator')
mod_by = meta.ForeignKey('self',
 related_name='modifier')


Running these through django-admin.py install results in:
Traceback (most recent call last):
...
line 21, in Location
created_by = meta.ForeignKey(Person)
NameError: name 'Person' is not defined

I didn't find any other references to this issue in the docs or the
list archives.  Has anyone figured out a way to make this work or
perhaps an elegant and functional work-around?

Thank you

Eric.

Re: befuddled with formfields.py

[Robert Wittams]

scottpierce wrote:
> See http://code.djangoproject.com/ticket/338.  The patch works.
> 
> Scott Pierce
> 
> 

So basically, mainipulators are completely useless when it comes to
ForeignKeys and ManyToManys and need to be hacked around in the view
function?

This is a horrible fix. I'm going to fix it properly...  I didn't
realise the admin views hacked it about that much

New Free Downloads

[Jimm]

Hello everyone!
After few months of hard work, my site with free downloads is finally
up and running. I have tried to create a site that goes right to the
point and cuts through all of the software downloads. Having read this
group for quite a while, it looks like there are a lot of knowledgeable
people here, so I'd love to get some feedback about my site if anyone
can spare the time. The site is located at
http://www.freedownloadsarchive.com/ and called "Free Downloads
Archive".


I think that website are quite good, but I'm not so satisfied with
others, so I'd be grateful if you could tell me what you think?


Thanks in advance,
Jimm, Webmaster of Free Download Archive
Download Free Software NOW: http://www.freedownloadsarchive.com/

TurboGears

[Andreas]

I just discovered TurboGears, another MVC web development framework
based on Python (turbogears.org). Judging from the 20-Minute-Demo-Video
it seems to be quite similar to Django, although lacking the slick
admin interface. What do you think about it? How does it compare to
Django?

Re: Money or Currency data type

[rapto]

Please, never a float. Use Decimal Type.
http://www.python.org/peps/pep-0327.html