My understanding of AOP is that it really shouldn't affect the process flow of a request. Partly because it would be messy for it to have access to the request (event, or whatever). And partly because it just isn't what AOP is for.
As Brian mentioned, things like logging are more appropriate. I have also used it for a notification type of service where if certain data changes, I fire off an email. The advice is not changing any data, but simply comparing old with new and acting upon that comparison. AOP seems to make more sense for behind the scenes type of stuff, not validation where a request will be changed based on the results of that validation. -- Matt Williams 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. > > 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. > > Thanks again mate, > > Rob > > -----Original Message----- > From: Brian Kotek [mailto:[EMAIL PROTECTED] > Sent: 08 October 2007 15:10 > To: CF-Talk > Subject: Re: AOP in ColdSpring and ModelGlue > > The fact that you're using Model-Glue should make no difference at all. If > it is, then you're thinking about it the wrong way. I see a few problems > with what you've said: > > - AOP is really meant to eliminate duplication by encapsulating a > generic, common process so that it can be reused across many method calls > or > components. I'm not sure validation really qualifies, since it is so > specific to the particular object or data being validated. Usual suspects > for AOP include logging, security, and data formatting. So I'm not sure > if > what you're doing really lends itself to AOP in the first place, since I > don't see how your code is reusable. The example you gave is hardcoding a > call to getName() which already means this advice is really not going to > work with other kinds of data. > - You're right that the advice has no access to the Model-Glue event > object. It shouldn't. You have access to whatever arguments were passed > into > the original method, and access to any return value from that method. So > if > your UserService returns an object or a struct indicating success or > failure, along with error messages, you can manipulate that before it > gets > returned back to the controller. > > Basically, if you can imagine dropping Model-Glue and having a web service > call your Service (and your advice), and having it work and return data that > the web service could use, then you're at the right conceptual level. > Whenever this won't work (for example, you're wanting the advice to have > access to the Model-Glue event object, which obviously would be extremely > difficult if the client was a web service instead of Model-Glue), it means > you aren't keeping your application layers properly encapsulated. > > Hope that helps. > > Brian > > On 10/8/07, Robert Rawlins - Think Blue > <[EMAIL PROTECTED]> > wrote: > > > > > > Now this is where I become a little confused, see, in the old days I would > > validate the data inside my controller, and if the data failed validation > > I > > would add a result of 'failed' and update the viewstate with an error > > message, then use the events xml definition to pass the user back to the > > form if the result of 'failed' was present. > > > > > > However, from what I can see here I have no access to the event object > > from > > my advice object, so I'm not able to add results or update the view state, > > All I can do is simply return a value, is that correct? How do I use the > > advice object to control the user back to the form with an error message? > > I'm feeling a little confused about it. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:290550 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
