On 10/8/07, Robert Rawlins - Think Blue <[EMAIL PROTECTED]> wrote: > > Hello Brian, > > Thanks a great deal for the detailed reply, it does help make things a > little clearer. You're right to say that my example was hardcoded values > and > this would most defiantly be difficult to validate using AOP, however in a > real working example I have a nice little validation service adapted from > Javier Julios data Validator component which allows me to define data > validation rules for variables by name, so the advice object would be > passing the variable 'name' off to the validation service and the service > would then find the correct rules for that variable and test it against > them > accordingly. So in my case, being able validate variables on the fly using > AOP is certainly plausible.
It sounds possible, but doesn't this essentially mean every variable name in your system has to be unique? What if I have a customer with a name and a user with a name? It seems like an odd way to perform validation, unless I'm misreading. I'm also still not convinced that just because it is possible means it's a good idea. It seems like validation is something you really want explicitly attached to the business object being validated, since these are really business rules. In other words, under what condition would you *not* want to validate a business object? Maybe it's just because I perform validation quite differently and I might be missing some underlying benefit of what you're proposing. (I have a Validator composed into my business objects, which handle validation using either database metadata or XML validation rules.) Like you say the general principle of this process should be identical > regardless of whether I'm using MG or not, however the problem that arises > with MG is that the only way I can currently see this working is to adapt > my > controllers so they contain a conditional which watches for returned > values > from the proxy, and if there is one then act upon it by pushing the user > back to the form, however this seems to totally eliminate the benefits of > an > AOP approach to the concerns as the whole point of AOP is to eliminate > code > which doesn't concern the business logic. > > If we're using something like before or after advice then this isn't a > problem as its effectively non responsive and has no control over the work > flow, however when trying to apply this 'about' advice, I can't see how it > can be done without defeating its own purpose of having to watch for > returned values. Unless of course we can give the advice object access to > the event object. Well you could always try to pass the event into the Proxy as an argument, but I think that would be a bad idea. I suppose my take might be: 1. Pass data into the AOP Proxy 2. AOP Proxy calls runs the validation rules on the incoming data. 3. If data is valid, pass the data on into the target Service object and let it do it's work 4. Proxy creates an instance of a Result object and populates it with errors array, messages, or whatever data you will need for later processing 5. Proxy returns the Result object to the caller (in this case the MG Controleller) 6. MG Controller can call something like result.isSuccess() to determine what results it needs to add to the event queue. Would something like that work for you? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Get the answers you are looking for on the ColdFusion Labs Forum direct from active programmers and developers. http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid-72&catid=648 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290552 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
