AOP in ColdSpring and ModelGlue
Hello Chaps, I've been working with both CS and MG for a while now and we're getting on famously together, It took me a while to feel comfortable with relinquishing that control over to the frameworks, but once done I can genuinely feel the development benefits, it's quite amazing. This past weekend I've made my first ventures into studying the benefits of the AOP concepts which are available to me in CS, and they have gotten me quite excited to say the least, however trying to find some good working examples of how to apply them within a MG/CS application is becoming quite tricky and I'm struggling to figure this stuff out, so thought I'd come looking for a little help. For the sake of argument and example, let's take a simple task like validating some data which is being passed to a service object. I'll give some basic mocked examples of my controller and advice object that I have at the moment. Controller: cffunction name=registerUser access=public output=false returntype=any cfarguments name=Event type=any required=true hint=I'm the event / !--- Create New User --- cfset var NewUser = VARIABLES.Instance.UserService.create(ARGUMENTS.Event.getValue(name)) / cfreturn ARGUMENTS.Event / /cffunction Now obviously that's very stripped down version of my controller method, but for the sake of argument let keep it as simple as possible. Now, I need to validate that 'name' variable to ensure that it doesn't have any numbers in it, if it does then I want to throw the user back to the form page with an error message. Take a look at my basic advice object below: Advice Object: !--- Advice Method --- cffunction name=invokeMethod access=public returntype=any hint=I supply the advice to the method call cfargument name=methodInvocation type=coldspring.aop.MethodInvocation required=false / !--- Create Temporary Local Structure --- cfset var LOCAL = structNew() / !--- Validate Data --- cfif refind([0-9], arguments.methodInvocation.getArguments().Name) !--- Data Not Valid --- cfelse !--- Data Valid --- /cfif !--- Return Out --- cfreturn / /cffunction 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. Thanks for any 'advice' guys, I really appreciate your time. Rob ~| 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-72catid=648 Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290526 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
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. Thanks for any 'advice' guys, I really appreciate your time. Rob ~| Check out the new features and enhancements in the latest product release - download the What's New PDF now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290539 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: AOP in ColdSpring and ModelGlue
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. Thanks for any 'advice' guys, I really appreciate your time. Rob ~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finderproductID=1522loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290544 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: AOP in ColdSpring and ModelGlue
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
Re: AOP in ColdSpring and ModelGlue
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-72catid=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
RE: AOP in ColdSpring and ModelGlue
Thanks Matt, I generally agree with you that it works best when not interrupting the application flow, i.e logging, however, It seems that everyone is quite happy to utilize AOP to implement security concerns, and obviously validating and confirming security credentials or authenticating a user is really no different to validating a piece of data, either can return true or false and need to be acted upon accordingly, or are they referring to something different when they discuss 'security'? Thanks guys, Rob -Original Message- From: Matt Williams [mailto:[EMAIL PROTECTED] Sent: 08 October 2007 16:04 To: CF-Talk Subject: Re: AOP in ColdSpring and ModelGlue 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
Re: AOP in ColdSpring and ModelGlue
On 10/8/07, Robert Rawlins - Think Blue [EMAIL PROTECTED] wrote: Thanks Matt, I generally agree with you that it works best when not interrupting the application flow, i.e logging, however, It seems that everyone is quite happy to utilize AOP to implement security concerns, and obviously validating and confirming security credentials or authenticating a user is really no different to validating a piece of data, either can return true or false and need to be acted upon accordingly, or are they referring to something different when they discuss 'security'? In general, a Security Advice would throw an exception if the authentication fails. It would then be up to the client code to handle the exception. ~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finderproductID=1522loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290558 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: AOP in ColdSpring and ModelGlue
Thanks Brian, Yeah I see your point about validation being a business concern, however, like you say because it is something that concerns all elements of the application, then does that not make it a cross cutting one? I've just done a little bit of hunting around on the web and there seems to be lots of articles for using SPRING (the JAVA father of CS) to implement a standard of data validation across the entire application, so it would seem the principle has been explored before. Now I agree that you should really be validating every business object, however I'm thinking about building this proxy layer between the controller and the model, and all data coming from the controller is generally user generated, from a form or url, and in my mind this is perhaps the best place to validate the data, before it actually gets into the business objects rather than once its arrived. Now the way in which I envisage the validation working would impose a certain amount of naming convention amongst my application, however this can work well for me, for instance, I have Users, Guests, Tech Support Staff, Suppliers, News Letter Subscribes etc ... now all of those objects have a First Name, Last Name, Email Address etc... so It makes good business sense to apply the same rule to all those objects, so they all have their variables named identically, i.e. FirstName, then I need only define one valuation rule, in one location for the variable named 'FirstName' and know that it is safely applied to all of my objects, and the data being passed into them. Does that make sense? This is a new concept that I knocked up over the weekend for me so it's still a little sketchy. Rob -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: 08 October 2007 16:10 To: CF-Talk Subject: Re: AOP in ColdSpring and ModelGlue 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
Re: AOP in ColdSpring and ModelGlue
On 10/8/07, Robert Rawlins - Think Blue [EMAIL PROTECTED] wrote: Now I agree that you should really be validating every business object, however I'm thinking about building this proxy layer between the controller and the model, and all data coming from the controller is generally user generated, from a form or url, and in my mind this is perhaps the best place to validate the data, before it actually gets into the business objects rather than once its arrived. I think this is where your approach will break down. I would disagree that the best place to validate the data is before it gets to the business object. In fact, for anything other than the most trivial validation, this can get very convoluted. Because what you really want to validate isn't the data itself, it's the state of the business object. So it's easy to pre-validate data based on very simple rules like this must not be empty or this must be numeric. But any complex property of the object requires actually using the business logic in the object itself to determine whether something is valid or not. What if I want to validate that the user's user name is unique (via a call to a data access object that is composed into the User object)? What if I want to validate that an Order is only valid if the associated customer has no outstanding invoices (order has a customer via composition)? Unless you're going to duplicate (or move) the logic to do this out of the actual business object, which I think would probably be a bad idea, trying to validate the data *before* it gets to the business object in question seems to rapidly hit a dead end. This is especially true if you are going the route of rich business objects that actually have behavior instead of being nothing but dumb beans (properties with getters and setters). All that said, it still doesn't mean you couldn't do this with AOP. It just means I would look at having the advice get the object from the service and then pass it into a validator. When I do validation, I usually do something like this from within my business object: getValidator().validate(this), which means the validator has a reference to the actual object itself and can call methods on it to validate it, rather than relying on nothing but the instance data which has no behavior at all. It's fairly easy to define rules that all validators can use (along with custom rules for specific situations), but again, I personally wouldn't try doing it with AOP. ~| Enterprise web applications, build robust, secure scalable apps today - Try it now ColdFusion Today ColdFusion 8 beta - Build next generation apps Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290564 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: AOP in ColdSpring and ModelGlue
Ah I see!, I hadn't considered the ramifications of the more complex validation, like you say, those that involve cross checks between objects and database calls, these would certainly be more difficult to implement using AOP or a generic class. I understand your thinking here completely. I have just started reading an article about a Validation framework built in JAVA which uses Spring and AOP, the idea being that you can implement a blanket validation process for these more 'trivial' tasks and data comparisons using AOP, which helps save development time, and then in the underlying model and business logic you can manually build these more complex validation checks. I think that building a system which allows space for both may work well, as it leverages the power of the framework to free up time doing the more trivial tasks and at least ensures a basic level of volition across the entire application, yet allows you to then extend that with non AOP business logic validation for the more complex data? Thanks again Brian, I hadn't considered those more complex validation problems, Rob -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: 08 October 2007 17:05 To: CF-Talk Subject: Re: AOP in ColdSpring and ModelGlue On 10/8/07, Robert Rawlins - Think Blue [EMAIL PROTECTED] wrote: Now I agree that you should really be validating every business object, however I'm thinking about building this proxy layer between the controller and the model, and all data coming from the controller is generally user generated, from a form or url, and in my mind this is perhaps the best place to validate the data, before it actually gets into the business objects rather than once its arrived. I think this is where your approach will break down. I would disagree that the best place to validate the data is before it gets to the business object. In fact, for anything other than the most trivial validation, this can get very convoluted. Because what you really want to validate isn't the data itself, it's the state of the business object. So it's easy to pre-validate data based on very simple rules like this must not be empty or this must be numeric. But any complex property of the object requires actually using the business logic in the object itself to determine whether something is valid or not. What if I want to validate that the user's user name is unique (via a call to a data access object that is composed into the User object)? What if I want to validate that an Order is only valid if the associated customer has no outstanding invoices (order has a customer via composition)? Unless you're going to duplicate (or move) the logic to do this out of the actual business object, which I think would probably be a bad idea, trying to validate the data *before* it gets to the business object in question seems to rapidly hit a dead end. This is especially true if you are going the route of rich business objects that actually have behavior instead of being nothing but dumb beans (properties with getters and setters). All that said, it still doesn't mean you couldn't do this with AOP. It just means I would look at having the advice get the object from the service and then pass it into a validator. When I do validation, I usually do something like this from within my business object: getValidator().validate(this), which means the validator has a reference to the actual object itself and can call methods on it to validate it, rather than relying on nothing but the instance data which has no behavior at all. It's fairly easy to define rules that all validators can use (along with custom rules for specific situations), but again, I personally wouldn't try doing it with AOP. ~| Download the latest ColdFusion 8 utilities including Report Builder, plug-ins for Eclipse and Dreamweaver updates. http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290568 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: AOP in ColdSpring and ModelGlue
I'm working on a validation system for Transfer (but the idea would probably port to other kinds of objects) that has a generic Validator class to handle common needs like required fields, field length, type, etc. But you can then define custom validation methods as well, which a subclass of Validator would implement and which would be specific to a particular kind of object (say, Order). The Validator will run the common and custom methods based on an XML file which defines the validation rules. As a bonus, I am trying to make it also able to generate client-side JavaScript (with an extensible implementation so that it can handle any JavaScript library such as jQuery, prototype, etc.) from the same XML. Which will allow you to define the rules once and have them applied on the client and on the server. If I can get it working acceptably I'll probably blog about it and/or post it to RIAForge. On 10/8/07, Robert Rawlins - Think Blue [EMAIL PROTECTED] wrote: Ah I see!, I hadn't considered the ramifications of the more complex validation, like you say, those that involve cross checks between objects and database calls, these would certainly be more difficult to implement using AOP or a generic class. I understand your thinking here completely. I have just started reading an article about a Validation framework built in JAVA which uses Spring and AOP, the idea being that you can implement a blanket validation process for these more 'trivial' tasks and data comparisons using AOP, which helps save development time, and then in the underlying model and business logic you can manually build these more complex validation checks. I think that building a system which allows space for both may work well, as it leverages the power of the framework to free up time doing the more trivial tasks and at least ensures a basic level of volition across the entire application, yet allows you to then extend that with non AOP business logic validation for the more complex data? Thanks again Brian, I hadn't considered those more complex validation problems, Rob ~| Download the latest ColdFusion 8 utilities including Report Builder, plug-ins for Eclipse and Dreamweaver updates. http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290598 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
