Why not use your decorator to decorate your other, non-Transfer objects?
Sent from my iPhone On 19-Nov-08, at 6:08 PM, "John K." <[EMAIL PROTECTED]> wrote: > > Elliott, > > I totally understand what you mean and you're right on with the car/ > gas can analogy. I know I'm wasting a bunch of functionality and if > I, or another developer, were to call just about any other method on > this object other than a getter/setter/decorator method, I'd get a > nasty error. > > All, > > What I'm trying to get at is, how do you rectify the two different > objects. We all know now the solution I came up with but what > strategy do you use? As it stands right now my Transfer object also > has at its disposal a validate method, added in the decorator, and an > ErrorCollection that it can use to store all validation errors. I > need all this functionality but don't want to have to maintain two > very different ways of creating/using objects. > > Mark, > > This is really your baby. haha. Am I totally bastardizing everything > it stands for? ;-) > > John > > > > On Nov 19, 3:03 pm, Elliott Sprehn <[EMAIL PROTECTED]> wrote: >> What worries me the most about about this idea is that it utterly >> breaks the insides of Transfer on a global scale. Essentially the >> entire public API that it provides won't work. That is, >> readByProperty >> () , readByPropertyMap(), TQL, saving, deleting, relationships... >> won't work. And it won't just fail silently, Transfer will throw >> nasty >> exceptions from the database. >> >> This sounds like a nightmare for a new developer later maintaining >> your project when they look at the transfer.xml, try to call save on >> some object or some such, or try to understand why your code does >> what >> it does. >> >> What transfer does internally when you create objects is also very >> very complicated for simple objects. It makes a lot of sense for >> something that deals with the database (and the dynamic property/ >> decorator stuff), but for general objects? It's incredible overkill! >> >> I think you're much better off rolling your own management system for >> Objects, assuming you even need the kind of caching that transfer >> provides for your app. It's pretty trivial to generate objects based >> on an XML file, or just use plain old CFCs. Why would you even want >> the massive duplication between properties and the XML if it's not >> going in the database? :P >> >> To me, using Transfer like this really makes no sense at all. You've >> taken a car and used it as a gas can. Does it contain the gas for you >> and tell you much there is? Sure. Are you wasting 98% of what's >> provided? Yeah... >> >> On Nov 19, 1:26 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> >> wrote: >> >>> It depends on how you look at it, if ORM is object --> relational, >>> then it's no misuse at all, you're using Transfer as an object >>> factory to get your business objects and if they happen to have >>> persistence integration well that's cool. >> >>> I'm glad I was wrong, FWIW, because this is cool. Sort of puts >>> another nail in the coffin of the notion that Transfer requires King >>> Database and puts the database before the object model. >> >>> I'm going to try to write a sample application that goes thru the >>> process of setting up a Transfer-based app without using a service >>> layer at all, just real, behavior-laden domain objects... because >>> there's no reason that Transfer can't take the place of the service >>> layer and the persistence layer all at the same time. Should be >>> interesting. >> >>> Laterz, >>> J >> >>> On Nov 19, 2008, at 11:45 AM, Bob Silverberg wrote: >> >>>> I like this idea. I can see how some might see it as a misuse of >>>> the >>>> ORM, but it seems like a very practical approach to me, and keeps >>>> things consistent (i.e., all Business Objects are Transfer >>>> Objects). >> >>>> Thanks for sharing, >>>> Bob >> >>>> On Wed, Nov 19, 2008 at 11:05 AM, John K. <[EMAIL PROTECTED]> >>>> wrote: >> >>>>> I didn't mean to make anyone go out and code this up for me to >>>>> see if >>>>> it worked, I was really just curious how others handled this >>>>> problem. >>>>> Thanks for trying it out though Chris! ... > > Sent from my iPhone --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" 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/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
