[Nitro] help with og!
rob at motionpath.com
Sat Dec 3 08:41:00 EST 2005
I also make use of transient unstored attributes on objects and would
be disappointed if this facility was not available.
On 3 Dec 2005, at 12:41, David Corbin wrote:
> 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,
>>>> in the constructor. Altrough, if a blank object can't be
>>>> 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
>>> If the other approach was taken, using just #attr methods, it
>>> would be
>>> neccessay to have a variant way to inform Og which instance
>>> 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
>>> 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
>>> 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
>> 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
>> 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.
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general