On 8/17/05, Matthew Marshall <[EMAIL PROTECTED]> wrote:
> As what I did in this patch really doesn't need to be ingrained into django
> itself, I was intending to move it into a wrapper class this evening. This
> would allow the use of this new syntax without requiring any change to
> django, so those who really want the new syntax can have it. Unfortunately,
> this would not be something which a new django user would see, and I think
> that a first 'wow' impression is one of the advantages of this new syntax.
By that, do you mean an alternate class to inherit from? E.g., instead of
class Person(meta.Model):
fields = (
meta.CharField('name', maxlength=50),
)
I would do
class Person(meta.PythonicModel):
name = meta.CharField(maxlength=50)
?
If that's what you mean, I'm about -0 on the idea. Its advantage is
that no change to Django is required, so the documentation can stay
the same, the tutorials can stay the same, and so on. Gradual ramp up.
But the disadvantage is... the docs stay the same, the tutorials stay
the same, and a new user doesn't immediately see the shiny "wow,
that's awesome!" syntax.
I think SQLObject got a lot of things right, except for using the name
MultipleJoin for what should have been called ForeignKey. The "Oh wow,
you can just declare your fields using class-attribute creation"
coolness was certainly one of the most attractive things about
SQLObject. It would be a shame to lose that for Django.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0xD6497014
