Sorry for the delay, in those weeks I'm very busy in development for a project in my company (evening included :-(). I hope to survive since next week.
It's correct Matthew! DataObjectImpl class cannot be derived directly and it represented a little trouble (but not so big). To be honest Business rules should be apply in two distinct context, one councerning the whole Entity (read table) and one councerning the single istance of a DataObject (if needed) to get two different behaviours for the general and for the specific case. All objects rapresenting an "author" table records should invoke a business class method (static) before their "name" properties change. One specific istance o a DataObject rapresenting a single record could invoke a busines object method (concrete object) before its particolar "name" property change. At the moment the "my" DataObjectExt incapsulating DataObject can preserve the correct reference to the relative Business Rule Class (or Object) and all can work well enough (i hope). A little trouble consisted of activating the rules before CRUD operations because SDO_DAS_Relational handle directly the DataObjectImpl istance that doesn't know which BusinessObject should be use (DataObjectImpl doesn't know BOs at all). A work-around consisted in registering any association of DataObjectImpl TypeName and Business Class in order to use that before add the corresponding Insertion, Deletion etc in the execution plan. it's a dirty solution but it is the less invasive I found. I remember you that InsertAction, DeleteAction, UpdateAction classes were extended for that pourpose. At the moment I think it is premature to speak about any implementation of DataObjectImpl without giving to you the opportunity to take a look of the code (I' m still preparing a clean example). Most probably you could find or suggest alternative ways using the DataObject and SDO_DAS as is. Last consideration about members and method visibility: All SDO_DAS_Relational,Action derived classes members and method that were "private" should be converted in "protected" in order to be used by derived classes. I'm going on (with time difficulties) to prepare the material. if there are further considerations do not hesitate to contact me. Dear Matthew and dear Simon... I hope to hear from you soon. Best regards, Antonello On 12 Mar, 17:58, "Matthew Peters" <[EMAIL PROTECTED]> wrote: > I agree, picking a simple scenario and seeing what the application > code would look like and the sort of pre and post-rules you would want > to apply would be very helpful and give us all something to focus on. > > Antonello, when you first mentioned this to me in an earlier note, I > seem to remember that you ran into problems because we had certain > instance variables as private when it would be more helpful if they > were protected. Is that still the case. I am getting the sense from > the above that you have had to work round that: that your > DataObjectExt contains a reference to a DataObject when you would > really rather have inherited from Data Object. Have I remembered that > right? I am interested in what we need to do in the implementation of > DataObject or the the Relational DAS to make it easier for you to > write the business rules layer you describe. > > Matthew > > On Mar 10, 4:00 pm, [EMAIL PROTECTED] wrote: > > > > > On 9 Mar, 11:17, "Antonello" <[EMAIL PROTECTED]> wrote: > > > > Hi Simon, > > > > Thank you for your replay. > > > > To help you to better understand the context i have to give you some > > > additional information. > > > > First of all the wish is to be less intrusive as possible. > > > The intention is to build a thin layer around SDO_DAS_Relational > > > related classes. > > > > To be concised: > > > > In SDO_DAS_Relational DataObjectImpl istance is the main object used > > > to set the varius changes to the underlying DB-Host. > > > The goal is to intercept both the moment in which DataObject changes > > > its state, or better when one or more of its properties are modified, > > > and when its general state change from "pending changes" to "changes > > > saved". > > > > Before and after those particular moments should be activate Business > > > Rules to do some particular actions ( verify logical constranis, value > > > ranges, setting default values and so on). > > > > At the moment one possible, simple way, could be used to get it. I > > > developed a simple prototype consisting of: > > > > A IBusinessObjectRule interface. All Objects containing Business Rules > > > should implements that interface. > > > > A DataObjectExt containing a reference to a real DataObject, a > > > reference to the related IBusinessObjectRule implementing class > > > object. > > > > Derivations of SDO_DAS_Reletional , SDO_DAS_Relational_UpdateAction, > > > SDO_DAS_Relational_InsertAction, SDO_DAS_Relational_DeleteAction > > > classes. > > > > Plus a FactoryObject Class to which to demand some propedeutic work. > > > > Some additional difficulties will be surely represented by the > > > impossibility to give a full control of the internal mechaninsm of > > > DataObject, in fact we are obliged to work only on its public and > > > external interface. DataObjectExt will be a simple, surrogate > > > DataObject using the "magic" __call, __set , __get methods to delegate > > > the corresponding invocations to the real DataObject below. Before and > > > After each invocation a corresponding call to the BusinessObject > > > method will be invoked. > > > > SDO_DAS_RelationalExt extending SDO_DAS_Relational class will oper on > > > the new creations of DataObject ( that will be new DataObjectExt > > > incapsulating DataObject) and on the applyChanges method, that will > > > use the extended classes mentioned above in order to invoke the > > > BusinessObject validations rules for the CRUD Operations before adding > > > the new command to the Execution Plan. > > > > I know that you have two solve two major problems at the moment: > > > 1) To immagine how does it could work. > > > 2) Understand my English. > > > > Well , we can going on if you are interested, also with other > > > discussion contributors. > > > Part of the source code is developed and it can be subject for > > > experiments and further consideration. > > > I can prepare a simple Class diagram and a Sequence diagram to help me > > > to be the more clear as possible. > > > > Waiting for yours notices and requests. > > > > Regards, > > > > Antonello > > > Hi Antonello > > > Thanks for the more detailed explanation I think I understand better > > now. Using the relational DAS to try this out is a good idea. It's > > much easier to develop in PHP:-) So some more questions. > > > - How do you register objects implementing IBusinessObjectRule with > > the DataObjectExt. Is this done on a Type, Instance, Property basis? > > - Following on from this does the object that implements > > IBusinessObjectRule manage all of the events in one place or do you > > create a new business object rule for each different event. I.e. is > > that there switch inside this object that determines what property you > > are dealing with and what the event is or do you create this > > association when you register the business object rule. > > - What is the repose to runing a rule. A new property value? A veto to > > the change? > > > A sequence diagram would be great if you can make one easily. It would > > also be good to have an example scenario so that we can talk about > > something real.. There are some SDO examples that use the relational > > DAS, for example, the contacts example (http://cvs.php.net/viewvc.cgi/ > > pecl/sdo/examples/SDO/contacts/). We could take one of those and > > describe how the business rules could be used to add some feature. Or > > we could just make one up. > > > Regards > > > Simon- Nascondi testo tra virgolette - > > - Mostra testo tra virgolette - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
