[Nitro] help with og!
transfire at gmail.com
Thu Dec 1 22:25:32 EST 2005
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.
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).
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
More information about the Nitro-general