My big reason for this. I have to deal with legacy tables that I can't modify. The View idea was pretty good, but it seems like the information about how a db maps to your application logic belongs in the application. The other downside of Views (for me) is that I work for a large company and the database in question is controlled by IT. They don't let us touch it, just consume it, so creating and updating Views would have to go through layers of red tape.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart Sent: Thursday, February 09, 2006 10:33 AM To: [email protected] Subject: Re: Reactor For CF Object Relational Mapping (just to be a wiseass devil's advocate) Why not just name your DB columns the same as you'd want the property names? Instead of this: Some -------------------- SomeId Some_Name Some_DateCreated Why not this: Some ------------------- SomeId Name DateCreated -Joe On 2/9/06, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > Now THAT is an idea I like. > > I really hate having all the elements from forms, URLs and objects act > like implicit bindings to match up to the DB. It makes things less > re-usable (unless you're really handy with the find/replace) and it's > just a forced dependency that might be handy, but can really make things awkward. > Especially since the name of a column might make sense in the context > of a record, but as a field name in a form is just oogly. What makes > sense as a column name make look ridiculous as a URL variable. Now, I > know I can do something in my controller like <cfset > MyObj.setFoo(arguments.event.getValue("bar"))> but if Foo===bar in > this scenario and does so consistently, why not let me map them > somehow so that I can just use the labels that make sense for my > elements and let Reactor sort'em out? > > In the XML laid out below, I'm assuming that code like this: > <cfscript> > // I assume that this: > MyObj.setSomeId(9); > MyObj.setName("Fred"); > > // Is a synonym for this: > > MyObj.setId(9); > MyObj.setSome_Name("Fred"); > > </cfscript> > > > > > > I have a situation where I'm getting data from PayPal, and their forms > are full_of field_names like_this. sender_email, address_city, and > mc_gross. So I end up with an ARF object that has the matching methods... > Ledger.getPayment_Status() or Ledger.setSender_Email(). It's almost > enough to give me a stomach ache. I'll grant you that it works, but > it's so damned ugly I can hardly stand it... and there's no way around > it because ARF provides no mapping capabilities whatsoever except > between related objects (so you can tell it that Account.accountId is > the matching key for ProposedTopics.submitterId AND for ProposedTopics.speakerId). > > > > > This sort of mapping concept would be awesome for adding that little > extra bit of abstraction that I've been wishing for. > > > > > Here Here Ryan! > > > > > Laterz, > > J > > > > > ------------------------------------------------ > > Jared C. Rypka-Hauer > > Continuum Media Group LLC > > http://www.web-relevant.com > > Member, Team Macromedia - ColdFusion > > > > > "That which does not kill me makes me stranger." - Yonah Schmeidler > > On Feb 9, 2006, at 11:21 AM, Miller, Ryan wrote: > > To follow up my questions on Views and in relation to the other > discussion about only saving certain values. > > Is adding some mapping capability to the config xml been discussed or > planned? > > Or does this little community prefer doing it's mappings via Views? > > I'm thinking about diving into the code to add support for something > like this in the config xml > > <object name="SomeClass" table="SomeTable"> > <fields> > <field name="someID" column="ID" /> > <field name="name" column="some_name" /> > </fields> > </object> > > I thought I'd just float the idea here to see if this has been > discussed or tried already before jumping in with both feet. > > Thanks, > Ryan Miller > -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com
