Hi Antonello, I know it has been a while since we last wrote anything.
We are all busy!

It was helpful of you to distinguish between the the two times that
you might want to drive business rules: on a property change, at any
time, or when writing a full set of changes back to the database.

On the first of these, I wish we had something better to offer you
than what you have done, which is to  encapsulate an SDO inside your
own business object(have I understood that right?). SDO is an extended
Data Transfer Object pattern, intended to allow you to move data about
between applications and languages, while remaining independent of
where the data came from. A data graph of SDOs might easily find
itself serialised and sent somewhere via a web service, then later
come back again, plus changes. Unless we can make business rules part
of the model that gets serialised and sent too, the objects might get
changed somewhere where the rules are not in operation.

The idea of driving business rules at the time that you apply the
changes back to the database is quite different though. If I have
understood correctly, we could make the private member variables of
the *Action classes protected, and that would help: that's because you
trigger that set of business rules at the same time that we apply the
changes to the databases, by inserting special classes derived from
*Action in the Plan. Here's an idea: you could of course read the
change summary yourself and drive your business rules that way, at any
time; though there is something more elegant about driving the check
during our applyChanges step. I suppose we could just simply allow you
to register a callback that we drive during applyChanges and let you
walk the change summary for yourself. It rather depends if you always
want to walk through the changes in the same order we do.

Well, I guess we still need to have a few simple scenarios to think
about.

Matthew

On Mar 16, 10:08 am, "Antonello" <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to