[Nitro] help with og!

zimba-tm zimba.tm at gmail.com
Fri Dec 2 05:40:00 EST 2005


On 02/12/05, TRANS <transfire at gmail.com> wrote:
> On 11/28/05, zimba-tm <zimba.tm at gmail.com> wrote:
> > The disadvantage I see to use attr, is that you can't specify the data
> > types. It would then be necessary to describe it somewhere else, like
> > in the constructor. Altrough, if a blank object can't be instanciated
> > without default parameters, then this cannot be done also.
> >
> > Any other ideas on this ?
>
> #attr can be overriden to allow for the annotations, in fact you may
> not realize it but they already are in Nitro/Og. The only difference
> between #property and #attr is that #property informs Og that the
> attribute exists for ORM-ing while #attr does not. The distinction is
> good in a way, in that a class can have an attribute that is not
> neccessariy mashalled to the database.

Do you have real-world examples that show it's really needed to have
unstored attributes of an objet ? I think KirbyBase will store them
all, but I might be wrong.

> Presently you can actually create a class in the normal Ruby way and
> then come back later and mixin the property information. This makes
> for nice SOC (seperation of concerns).

Yes this is pretty. I was thinking about another approach, where you
tell Og store X to manage class XY or every class in a module. So all
that would be needed is to give a module name to Og.setup.

> If the other approach was taken, using just #attr methods, it would be
> neccessay to have a variant way to inform Og which instance varaibles
> should be, or at least should not be, mapped to the database. If
> you've ever used much YAML you'll know how it does this via the
> to_yaml_properties method --you'll need something like that. Given
> that most Og classes have all their instance vars mapped to the DB, it
> might actually be workable if there was just a simple way to _exclude_
> instance vars if need be. That might be a simple as
>
>   attr :x, :exclude => true
>
> or something. But since using #property is generally how the class
> gets "enchanted" an alternate way to do that would be needed as well,
> but it seems like the main idea of this in the first place is not to
> have to do anything special to the class, like 'include Enchanted' or
> something.

If "attr" would be used, it's better to not extend it. After all, the
goal is to create classes that are not dependent of the ORM and if we
need to extend attr, then there is no reason not to use "property".

An alternative would be to rely on the constructor. I think an object
should be instanciable with only default parameters. Maybe it's
doesn't validate, but it should be instanciable. It's also usefull to
create "empty" objects that can be stored in the sessions and filled
by multiple form pages (using continuation?) unless they are valid and
can be transferred in the database.

So Og can create an empty object, and detect the attribute's types.
What do you think of that idea ?

--
Cheers,
  zimba

http://zimba.oree.ch




More information about the Nitro-general mailing list