>Are you extending base_service in your other CFCs? That seems >to be a bit dangerous since it introduces a very tight >coupling, it doesn't represent an "is-a" relationship and it >prevents services from being genuine extensions of other CFCs.
No, only service CFCs extend base_service. The reason being that base_service is a cfc that provides default methods and variables for all services. I specifically created base_service so that it and the CFCs that extend it would represent an "is-a" relationship. For other applications it may well make sense to use something other than base_service so that services can extend other CFCs, but for what I'm doing right now it does make sense. I'd probably go for providing the service through composition rather than having a service extending some other type of CFC, but that would depend on the project. >Note: Mach II differs here a little because it's Controller >layer exception handling is very lightweight. Throwing >exceptions in Mach II results in an exception event occurring >which is then handled by the normal Controller process, >although you can re-map events and ultimately you write the >exception event handler(s). However, Spike's point is - I >think - that exceptions represent internal application control >flow and that should be handled by the Presenter (Spike, am I >right there?). I think what you are saying is correct. There is normally one or more presenter CFCs that are dedicated to handling exceptions/errors. Say you update the email address in your user profile and are sent a verification email, then hit refresh so 2 emails get sent. You click on the link in the first email that arrives, but the verification code is no longer valid. This will raise an exception in the model when it fails to find the verification code in the users database table. The type of exception would be something like 'dataIntegrity.invalidEmailCode'. The presenter CFC responsible for dataIntegrity exceptions would have a method to handle exceptions of type 'dataIntegrity' and may or may not have a specific one for exceptions of type 'dataIntegrity.invalidEmailCode'. The idea being that you can throw the dataIntegrity.invalidEmailCode exception from anywhere in your model and your application will always handle it in the same way without you having to put the exception handling logic into the verifyEmailCode() method that would handle all normal situations. Since the same type of exception is often thrown in different parts of an application and exceptions tend to interrupt the normal page display it seems like a sensible way to go. When to pass an error to the exception handling system and when to trap it in the presenter method where it occurs is a bit more tricky because you will often have form submissions where a form field is required, or an email address is already in use. I categorize these as data validation errors and tend to catch them in the presenter method that made the call to the Model layer. This allows me to easily re-route back to the form where the data was entered since the form and action methods are always in the same presenter. I pass the validation error data as an optional argument to the form generation methods so user friendly error messages can be displayed in the context of the form that was just submitted. If the exception is allowed to go to the exception handling system it gets more complicated with getting back to the original form and passing the data around. Spike > >Sean A Corfield -- http://www.corfield.org/blog/ > >"I have always wished that my computer would be as easy to use >as my telephone. My wish has come true - I no longer know how >to use my telephone." >-- Bjarne Stroustrup > > >--- >You are currently subscribed to cfaussie as: >[EMAIL PROTECTED] To unsubscribe send a blank email to >[EMAIL PROTECTED] > >MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia >http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
