Peter said ... 'I don¹t currently have the use case for different validations, but I¹ve had it in the past (although back then I just solved it procedurally). I¹d be tempted to EITHER have different isValid() methods, or more likely to have a OrderState control which would allow me to set the state (and hence validations and the like) for different states, so I might do:
Order.set(³State², ³Situation1²); If (Order.isValid()) ' ****** This was how I handled different validation rules for different processes. If a user was registering on the 'full registration' page or on the 'quick register' page then State / Strategy pattern was used to compose the User bean with the appropriate validation bean. All State/Strategy objects had a validate() method. User.validate() was called on the User object and this simply called CurrentValidationObj.validate() (ie encapsulating the fact that other objects were being used to do the validation The benefit of this was that if new processes came along then a new State/Strategy subclass was all that was needed and some code in the service to set the correct validation object (all validation objects were given to it by the Factory when the bean was created but only one of these was the 'active' validation (so more State than Strategy maybe)) The downside is that the User bean then becomes slightly dumber as it delegates its validation to other objects. Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
