Hello Keith, yes there are plans, however i haven't found somebody for this task yet :-) Do you have time? :-) From the Zend_Db_Mapper_SqlQuery and SqlQueryBuilder objects you can already see that building your own query object is not too complex and can be done as a standalone task.
greetings, Benjamin On Thu, 10 Sep 2009 13:05:29 +0100, keith Pope <[email protected]> wrote: > 2009/9/10 Benjamin Eberlei <[email protected]>: >> >> The approach you are describing is misusing Zend Entity as a data access >> layer >> only, however its purpose is really managing of object identities. >> Although >> its possible to dynamically set a different metadata model based on >> properties >> its really not recommended at all and there will be no support with >> whatever >> problems might occur with this use case. >> >> Instead a good use-case would be nest the ACL inside your entities and >> allow >> the request of certain data/relations only if these acls are meet. This >> way >> you push the access of different properties to the domain model and >> abstract >> from the persistence, which is what Zend Entity is about. >> >> It seems however with what you describe Zend_Db_Table is a pretty good >> access strategy for your relational data, Zend_Entity however is about >> objects that are instantiated completly. Partially loaded objects won't >> be >> supported. >> >> greetings, >> Benjamin > > Are there any plans to have a criteria type object for creating > repositories? > >> >> On Wed, 9 Sep 2009 16:43:19 -0700 (PDT), Chris Murray >> <[email protected]> >> wrote: >>> Chris Murray wrote: >>>> >>>> So I need to be able to dynamically set the property list in >>>> Zend_Entity >>>> >>> >>> Another possible approach would be to create my own def object >>> generator. >> I >>> already have my definitions in my model and they are used for other >>> purposes, such as form element configs, formatting, and display >> properties. >>> So, I could build the def object and pass it to >>> Zend_Entity_MetadataFactory_Code (rather than passing in a file path). >> That >>> way, I don't have to create multiple def files for each unique >> combination >>> of properties that are used in my application. Instead, just build the >> def >>> object dynamically based on already existing, multi-purpose object >> property >>> lists and their individual attributes. >>> >>> Is that a better way to do it? >>
