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


--~--~---------~--~----~------------~-------~--~----~
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