Kevin Dangoor <[EMAIL PROTECTED]> writes:
> On 2/15/06, Alberto <[EMAIL PROTECTED]> wrote:
>> I think it wouldn't be *that* easy to implement either, as you'd have
>> to traverese the full path to the desired attribute... what if one of
>> the intermediary attributes is a callable? (well, ok, it could be a
>> property...). it remind's me of Cheetah's name lookup mechanism (though
>> maybe my memory is not good at all :). I think it's too much magic for
>> just a little datagrid ;)
>
> Oops. I missed the "." in Jorge's strings. The best bet to do what
> Jorge suggests would probably be eval, and if we're doing eval we may
> as well just stick with a lambda.
Hi Kevin.
I don't like eval and I try avoiding it at all costs, so if only using eval
this can be changed, keep it as it is.
But I still don't get why there are two different approaches to the same
problem. Isn't the value passed to SQLObject? Why not pass everything that
is str/unicode to it and let it handle the search?
(lazy_gettext('Cliente'), 'nomeAbreviado'),
This is one column for a FastDataGrid. It will get the nomeAbreviado
attribute from the SQLResultSet (I dunno if this is the correct class, but it
explains what gets to FastDataGrid) and show it on screen.
If I have a foreign key, using SQLObject alone I could do:
print object_with_resultset.some_foreign_key.field_in_other_table
SQLObject then returns me 'field_in_other_table' without any problem. Since
with FastDataGrid we omit 'object_with_resultset' (it is implicit) then I
expected some_foreign_key.field_in_other_table to work.
For example, I have the following tables:
================================================================================
class Unidade(SQLObject):
class sqlmeta:
cacheValues = False
lazyUpdate = True
simbolo = UnicodeCol(length = 9, unique = True)
nome = UnicodeCol()
class ConversaoUnidade(SQLObject):
class sqlmeta:
cacheValues = False
lazyUpdate = True
origem = ForeignKey('Unidade')
destino = ForeignKey('Unidade')
multiplicador = FloatCol()
================================================================================
Here "ConversaoUnidade" (UnitConversion) is a table that makes a relation
between two units of the "Unidade" (Unit) table. (Examples of units: meter,
kilometer, etc.).
Here I can either work with ConversaoUnidade.origemID or
ConversaoUnidade.origem.id that I'll get the object ID, using
ConversaoUnidade.origem.simbolo will retrieve the symbol of the corresponding
unit instead of its ID. This is transparente to mee and is a facility that
SQLObject already provides.
Today to achieve the same thing with FastDataGrid I have to use a lambda like
the one below:
(lazy_gettext(u'Símbolo de Origem'), lambda unidade:
unidade.origem.simbolo),
Instead of the more natural syntax:
(lazy_gettext(u'Símbolo de Origem'), 'origem.simbolo'),
This second -- and more natural syntax -- is exactly the same that is used
when I'm retrieving an object in the first level. And it is a direct
application of SQLObject's properties.
I can live with lambda, but it isn't as natural and intuitive as using the
same syntax everywhere I use an SQLObject resultset, what introduces another
way of doing things.
--
Jorge Godoy <[EMAIL PROTECTED]>
