Peter I like what you are saying.
When do you use a service by the way? You seem to be interacting directly
with beans a lot.
Second, if you had varying levels of validation complexity for orders such
as:
- Situation 1: Validate Order, User, Billing, Statistics (the previous
example)
- Situation 2: Validate Order, Shipping
- Situation 3: Validation Order
Would you then have different aggregate validations? I.e.
Order.isValidSituation1(), Order.isValidSituation2(),
Order.isValidSituation3()
Cheers,
Baz
On Jan 14, 2008 12:34 PM, Peter Bell <[EMAIL PROTECTED]> wrote:
> How about:
>
> If (Order.isValid())
> {
> Order.save();
> }
> Else
> {
> Screen = OrderForm;
> Data = Order;
> };
>
> First method could both return a boolean as to whether the order is valid
> (which would only be true if all of the composed objects were also valid)
> and would also set all of the necessary error messages within the Order (and
> the composed beans) so you could just pass the error (containing both the
> data and the associated error messages) back to (say) a form for displaying
> the issues.
>
> I think it'd be straightforward to have a generalizable solution to this
> which would use relationship metadata and introspection to get the order to
> automatically ask all composed beans and properties whether they were valid.
> I see something along the lines of:
>
> Valid = 1
> For each property:
> If NOT THIS.isValid(PropertyName)
> Valid = 0
>
> And the isValid() method would call the appropriate type of validation
> depending on the data type of the property. If the property was a composed
> bean, it'd just call that beans general isValid() method. Then you just need
> a errorMessage(PropertyName) method which would display the error message
> for each property (it'd be null unless the property was invalid). Details
> beyond that would depend on relationship between validations and properties
> and whether you just look for one error per property or catch them all (
> i.e. could a single property have multiple error messages at any one
> time).
>
> I don't see any need for either service or controller to do anything here
> – that seems a little procedural to me.
>
> Best Wishes,
> Peter
>
>
> On 1/14/08 3:21 PM, "Baz" <[EMAIL PROTECTED]> wrote:
>
> Hey Peter, so you are doing the equivalent of a separate validate() and
> save() right on the bean itself, which, in this example, doesn't make too
> big a difference. But some problems can arise if we look at a more complex
> yet realistic use-case.
>
> Let's say a user submits an order and we need to:
>
> - partially update the user (perhaps they changed a communication
> preference during the order process)
> - create an order
> - create a billing address
> -
> - update an independent statistics table that executive management
> uses
>
> There are several objects involved here - possible composed, possibly not,
> it doesn't really matter - and each would probably have a layer of
> validation. One way of performing the save is to have one main function
> saveOrder() (located in some service) that goes about creating, validating
> and saving each object then aggregating the error messages into one final
> ErrorCollection. This provides a nice, clean, simple interface for a complex
> process. But then what do you return from that function - just the
> ErrorCollection? What about the objects at hand, such as the newly created
> billing address, how do we get references to those? Perhaps we can reload
> everything on a subsequent broadcast, but using which OrderID?
>
> On the flip side we can break apart the jumbo method and start calling
> smaller methods independently each of them returning appropriate data that
> we need back to the controller. But of course, the more you do that, the
> smarter your controller is getting and the less re-usable your code.
>
> So the tighter and cleaner you make your service functions, the more
> awkward or problematic the returntypes. And the more flexible or atomic you
> make the service the more intelligence your controller has to hold. In the
> aformentioned case it seems that there is no level of real cleanliness.
>
> Thoughts?
> Baz
>
>
>
>
> On Jan 13, 2008 6:20 PM, Peter Bell <[EMAIL PROTECTED]> wrote:
>
> Hi Baz,
>
> I can't think of a case where I'd be saving 10 independent objects. In my
> experience, I'm either saving one object, I'm saving a collection of objects
> of the same type (e.g. To update the price on 8 different products using a
> single form or grid) or I'm saving an object which may have composed or
> associated objects that also require saving.
>
> My real code assumes a collection of n-objects of the same type, and a
> single object is just a special case where n=1, so imagine the code I sent
> you within a cfloop and you'll get the idea. For composed objects I let my
> ORM do the lifting. If I really had a use case where I had to save multiple
> completely independent objects (that don't have any association or
> composition relationships) , I'd probably create an appropriate service
> class for handling that and would write a method within it that would
> orchestrate the independent method calls to the various object services. To
> date that use case has never arisen in the projects I've built.
>
> As for returning errors, I've been playing with a number of different
> approaches since obviously you want both the bean data and the error
> messages. I'm moving towards something like:
>
> If User.isValid()
> User.save()
> /If
>
> And with a User.getInvalidFieldList() and/or a User.isValid(PropertyName)
> and User.errorMessage(PropertyName). Also, as this is an IBO, it can
> contain a collection of users, so I can loop through them and store
> validation status and error messages for each, making this equally easy to
> work with for one object or for a collection of objects as the single is
> just the special case of n-objects where n=1. With this approach, I just
> pass the bean around and it contains both the data the user tried to enter
> and the associated errors.
>
> Right now I do something a little different each time I touch validation
> so I can get a feel for the different approaches and decide what to
> standardize on.
>
> Best Wishes,
> Peter
>
>
>
> On 1/13/08 8:40 PM, "Baz" <[EMAIL PROTECTED]> wrote:
>
> If the form submission was a lot more complex and required the saving of,
> say, 10 different objects. Would you still interact with each object
> individually in the controller, or move all of that to a service function
> that orchestrates the interactions? If you would choose the latter, and
> given that in the another post you said that you would handle the creation
> of objects in the service rather than the controller, you are then faced
> with the issue of how to return the bean(s) and/or errorcollection from the
> save() method...
>
> You know?
>
> Baz
>
>
> On Jan 13, 2008 5:15 PM, Baz <[EMAIL PROTECTED]> wrote:
>
> Hey Peter,
>
> Looks very tidy! So I guess the validation occurs in the save() method.
> What would that method return, True/False? And then later on you would
> evaluate the result to see whether to retrieve the error collection?
>
> Cheers,
> Baz
>
>
> On Jan 13, 2008 5:08 PM, Peter Bell <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > wrote:
>
> Hi Baz,
>
> Why not just:
>
> var Result = ";
> var User = UserService.new(User);
> User.LoadStruct(form);
> Result = User.save();
> AddResult(Result);
>
> I have some generic code so I don't have to type this for every controller
> that handles a form, but this is generally what I do.
>
> Best Wishes,
> Peter
>
>
>
> On 1/13/08 8:00 PM, "Baz" <[EMAIL PROTECTED]> wrote:
>
> Another design choice I see go both ways is whether to perform validation
> in the save() method or to call each method separately. Example controller
> functions could be (pseudo code):
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
>
> *SEPARATE SAVE & VALIDATE
> *var UserService=getBean('UserService');
> var FormVariables=getAllValues();
>
> var ValidationResult='';
> var SaveResult='';
>
> set ValidationResult=UserService.validate(FormVariables); // returns an
> error collection object
>
> if ValidationResult.hasErrors()
> setValue('ReturnObject', ValidationResult);
> addResult('Fail');
> else
> set SaveResult=UserService.save (FormVariables); // returns a
> populated user bean object
> setValue('ReturnObject', SaveResult);
> addResult('Success');
> end
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
>
> *COMBINED SAVE & VALIDATE V1.0
> *var UserService=getBean('UserService');
> var FormVariables=getAllValues();
>
> var UserBean=UserService.newUser();
> var SaveResult='';
>
> set UserBean.setMemento(FormValues);
> set SaveResult=UserService.save(UserBean); // returns true if saved
> successfully, or false if validation errors exist (the error collection
> would be saved in the bean itself for retrieval later)
>
> setValue('ReturnObject', UserBean);
>
> if SaveResult is True
> addResult('Success');
> else
> addResult('Fail');
> end
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
>
> *COMBINED SAVE & VALIDATE V2.0
> *var UserService=getBean('UserService');
> var FormVariables=getAllValues();
>
> var SaveResult=UserService.save(FormVariables); // returns a complex
> result object with properties: STATUS ('Success', ValidationError') and
> PAYLOAD (that contains either a UserBean or ErrorCollection depending on the
> STATUS)
>
> setValue('ReturnObject ', SaveResult.getPayload() );
>
> if SaveResult.getStatus() is 'Success'
> addResult('Success');
>
> else SaveResult.getStatus() is 'Validation'
> addResult('Fail');
> end
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - -
>
> CONS OF KEEPING THEM SEPARATE:
>
> - Controller has to be smarter, which is bad, because there will be
> more code duplication if you change the presentation layer to flex, for
> example.
> - Function coupling: Coders have to "remember" to always validate()
> before saving() - an unnecessary additional complexity (unless, of course,
> there are times in your app where you save() by defining all values
> yourself
> (thereby knowing the values are correct) rather than from user input)
>
> CONS OF COMBINING THEM COMBINED
>
> - Requires complex and unnatural result handling (either by
> affecting the bean by reference, or using a special RESULT object)
>
>
> Cheers,
> Baz
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
