I used a car as a gas can only once. My father would do it all the time tho' when I was young, so I probably learned it from him.
He had this 3/4" diameter white plastic tube hanging in the garage about 2 meters long or so. He'd open the cover on the car's gas tank, feed the plastic tube down into the tank and then suck on it until his mouth started to fill with gasoline. Then he'd jam his thumb onto the end of the tube as he quickly pulled it out of his mouth, spitting the gasoline out behind him as he lowered the tube down to the lawn mower tank, and carefully opened the end to fill the lawn mower (or whatever else needed gasoline.) Like I said, I only tried it once - BLAH! - but my father would do it all the time. Seemed to fit with his 1950's greaser personality. On Thu, Nov 20, 2008 at 12:08 AM, 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! ... > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
