On Wednesday 17 August 2005 09:28 pm, Robin Munn wrote:
> On 8/17/05, Matthew Marshall <[EMAIL PROTECTED]> wrote:
> 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)
>
> ?
Pretty much, yes. I imagine it as more of:
from djangomodelwrapper import Model, fields
class Person(Model):
name = fields.CharField(maxlength=50)
So, it would be completely separate from django, and thus easier for me to
maintain. (I'm getting sick of my django install breaking every time I do an
update that modifies a model.)
> 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.
Yeah, that is 100% what I was saying. Or at least, meant to say. I only
mentioned it because that is what I will do for my own use, should the syntax
not be included in django itself.
> 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.
My thoughts exactly. In fact, that is the primary reason why I would want
this included in django. For my own use, it really doesn't matter. I can
use the syntax with a wrapper, even it if isn't included.
MWM
