Hi Antonello, Thanks for you very interesting note. I tried to send this yesterday but for some reason it didn't arrive at the list:-(. In the Relational DAS at present the SDO change log is read to provide and event stream used to build the SQL activity for the back end database. At least that's what I think happens. You are suggesting here that we could provide event handlers for more general processing, e.g. validation, which sounds interesting.
You suggest a few places where it might be useful to allow BEFORE and AFTER event handlers to be attached. From your notes... on SDO Instance or SDO Type API Events for property add, read, update, delete API Events for propert not found on SDO Instance or SDO Type or DAS Change summary events for persistance layer interaction (Not clear to me that this would have to be handled separately from the API events but I guess you may want to register API style events that only get fired during SDO persistence actions, i.e. the same events but at a different time) I guess the event API should provide either a modified value or veto the request? Given this It would be useful to start to enumerate the kinds of scenarios you envisage so that we can discuss if the proposed features are fit for purpose. For example, (again from your notes) Apply data validation (property or cross property) to changes made to an SDO though the SDO API Apply data enhancement, transformation etc. Create derived data/virtual fields (maybe would need and event handler that fires if a property is asked for that doesn't exist) Do you have other in mind? Some more comments in line.... Regards Simon On 8 Mar, 09:28, "Antonello" <[EMAIL PROTECTED]> wrote: > Hi to All, > > I'm new of this discussion group. > > In the last weeks Matthew and me had a little duscussion about to give > to the developer the possibility to add Business Logic to the > DataObject ( especially DataObjectImpl object ) using a well defined > pattern. > > The Idea consists of build a mechanism to intercect the state changes > of the DataObject, that is, before and after any change of its > internal data member and before and after CRUD operations. > > At the moment this kind of implementation is limited (it's a > prototype) to the SDO_DAS_Relational branch of the project but it > could be easily extended to the XML, involving the webservices use in > the next future. > > The advantages of this kind of implementations could be: > > 1) Write Business Classes (classes implementing particular BO > interfaces) that can be attached dynamically to a particular Type of > DataObject. That is, every time a DataObject's property is to be > changed a Business Class Method will be invoked to apply the correct > rules, returning the status of the operation to choose to going on > with the property change. > > 2) Write Business Object that can be attached to a particular istance > of DataObject Or a Type or a DAS? > > 3) Write Business Class containig validation rules to apply before and > after data persistence operations. Is this directional, i.e. you are talking before and after w.r.t reading data from persitent storage and into a data object. There is another before and after when writing data from a data object to persistent storage. > > 4) Add to an DataObject Class properties that don't have DB fields > correspondance. Using them as volatile fields than can be use for > different pourpose even if they can be validate by Business Rules as > well as all other members. Interesting idea > > 5) Centralization of all the Business Validation Rules and Operations > with all the advantages for interchanges of "intelligences" or only > for mantenaince semplicity. > > 6) Association between Business Class and DataObject Type ( seen as > Business Entity ) should be defined also in configuration files ( XML > definition for istance ) permitting to switch from an hard-coded > behaviour of the application to a meta-data defined one. We have tried to avoid XML configuration files in our PHP activities. We have use PHP Documentor style comments in SCA to present meta data to the runtime. Maybe we could do the same again by anotating event handlers with the data types, events and scope they relate to > > 7) A great abstraction level and a defined separation from data logic > and presentation could encourage developers to apply the patterns that > more fit their needs ( MVC, Pipelines etc etc) > > 8) This additional layer will be written entirely in PHP. Not sure we can do it all in PHP. Unlike the Relational DAS the XML DAS and SDO API are written in C++. Doesn't mean it can't be done just a little more work:-) > > Some aspects will be also well considered in deep accourding with the > possibilities offered by the SDO_DAS_Relational framework. More work > and considerations will have to be done to build a all needs inclusive > solution (accourding with human possibility :-)). > > This post would be a starting point to discuss this issue, get > suggestions or particular needs, verify the interest of this groups > about it, and to give information to you to get a better idea of the > solution. > > Thank you for your attention, > > Best Regards, > > Antonello --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
