@Paul: Wow. Sounds pretty nice. @Bob: The thing I like about the decorator is that it *doesn't* tie you to Transfer. If I removed Transfer from my domain model tomorrow, the changes to the domain objects (i.e. decorators) would be: 1. remove the extends= attribute from cfcomponent 2. implement any getters and setters that Transfer, in its guise as a code generator, previously provided. Done! Of course, now my domain model is no longer persistable...
Jaime -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Bob Silverberg Sent: Saturday, 12 January 2008 5:23 AM To: [email protected] Subject: [CFCDEV] Re: Javascript validation and CFC's Sounds very similar to what I'm doing, except that I don't define the rules inside the decorator (I'm using Transfer as well). I had originally thought of doing that, but I didn't want to tie myself to Transfer as an ORM, so I thought it best to keep that stuff out of the decorator. This is actually something I have often struggled with. I love having the Transfer decorator, but then I'm concerned about putting too much in there as suddenly the business logic of my app is tied to Transfer. So instead I'm injecting components into the decorator. Any thoughts on that issue? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
