projects.
What I do is:
1.- Internally, Zend_Db_Table_Row has a "_data" property (and a
_cleanData). All columns/value pairs will be setted to "_data" array.
2.- Extends Zend_Db_Table_Row to create YourOwn_Db_Table_Row class.
3.- Add to this class the "_otherData" property, that will be an array
to hold the variables that doesn´t form part of the columns structure.
4.- Overload the magic metthods "__set", "__get", "__isset" and
"__unset" to work with this 2 arrays as if they were only one:
__get: first will try to return the variable from _data and if it is
not finded will try to get it from _otherData
__set: setting a var to the row will need to check if the "name" of
the var is a column (can do this checking the cols structure of the
table with table->info('cols')); If the var to be setted forms part of
the column structure, then it will goes to _data, everything else will
go to "_otherData" array.
__isset: needs to check in both _data and _otherData to return if a
var is set
__unset: needs to check in both _data and _otherData to unset a var
With this class, you can keep your row data completely clean, but
also, you will be able to assign vars to it without problem.
El 30 Oct 2008, a las 11:26, Joachim Lous escribió:
> Can I add a data to a table row class _without_ it interfering
> with the db-mapping?
>
> I'm finding it extremely useful to map my tables to custom
> Zend_Db_Table subclasses,
> and set them up to return objects of custom of Zend_Db_Table_Row
> subclasses .
>
> I extend the row class with custom methods for inspecting and
> manipulatiing
> them in no-trivial ways, and can still just save them afterwards. So
> far so good.
>
> The problem arises when want to extend the class not just with methods
> but also with variables. Variables that do not match any db column.
> This is
> useful for caching the results of expensive operations, and to be
> able to use
> the same instance as return value for several calls). If I simply
> add a custom
> variable, save will not work, no matter what access policy I put on
> on it.
>
> Is there any way to exempt variables from the automatic db-mapping
> without
> going deep behind the curtain?
> Are there any builtin variables that could be used to 'hang' my
> custom data
> under without disturbing how the rest works?
>
> If not, consider this a feature request.
>
> Some possible designs, in my order of preference:
> 1) A flag that exempts all 'private' and 'protected' fields from
> mapping,
> not just the builtin ones.
>
> 2) A prefix that will exempt any variable names starting with it
>
> 3) An overridable method that clears an attribute name for db-mapping
> (this should probabaly be the underlying mechanism anyway, the
> default
> implementation perhaps being one of the above)
>
> 4) A builtin "extra" protected field that is never included, just
> like the
> other builtins, dedicated to user data.
>
没有评论:
发表评论