[Nitro] help with og!

David Corbin dcorbin at machturtle.com
Sat Dec 3 07:41:54 EST 2005


On Friday 02 December 2005 05:40 am, zimba-tm wrote:
> 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.

Well, real world experience.  We do it all the time where I work.  It's a 
common optimization technique.  Say a model object is responsible for 
generating a bitmap.    You might want to only generate it once, on demand.

>
> > 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.

In an ideal world, it would be impossible to construct an invalid object. Some 
objects have no concept of 'default' parameters.  It just doesn't make sense.




More information about the Nitro-general mailing list