[Nitro] help with og!

rob 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,  
>>>> 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.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general




More information about the Nitro-general mailing list