When we
pass data into a function, we pass in each individual field instead of an
object. This has the benefit of allowing most of our functions to be
exposed directly as webservices with no modification whatsoever, and
without
worrying about compatibility with our target platforms due to strange
cfargument name=objargs required=no default=#arguments#
But you specify argument types this way.
On Thu, 27 Jan 2005 09:32:03 -, Kerry [EMAIL PROTECTED] wrote:
When we
pass data into a function, we pass in each individual field instead of an
object. This has the benefit of allowing
On Thu, 27 Jan 2005 13:34:14 -, Kerry [EMAIL PROTECTED] wrote:
yeah i know about argumentcollection, but i like being able to call the
function like this:
myobj.foo(form);
just laziness on my part i guess (but it just looks nicer than
myobj.foo(argumentcollection=form) !!!)
For performance reasons. I still use OOP as much as possible, but not the
DAO pattern in particular. OOP and DAO/BO in particular add a level of
abstraction that I don't really need (or necessarily want). There is an
inherent performance hit in the pattern for one, in that you're constantly
On Thu, 27 Jan 2005 14:33:52 -, Kerry [EMAIL PROTECTED] wrote:
But why make the rest of us programmers figure out your proprietary
objArgs technique?
in this particular case, my boss would be very happy if i made the app
incomprehensible to anyone outside the company, but i see your
What if you grow hire a new developer? You may not want outsiders to
know how to use your app, but there's no reason to confuse a new hire.
not a problem in our situation. and i dont think its that muddy, other
developers here love it compared with the API of some enterprise products we
use.
Surely if the arguments are named,typed and/or required, then the outside
world needs very in depth knowledge of what to pass? unlike in my scenario?
(Keep in mind that this is all my opinion, and that I am still rather
new at this as well.)
The outside world knowing what you need to pass is
Kerry,
Ummm ... so far as an object is concerned, i think you are included in the
outside world just as well as i am. In fact, i think that's the point!
As i move deeper into this stuff, type checking via the arguments in a
method has immediately indicated to me via an obvious error in my face,
What is this object that has a getConfig() method? Is it a bean
and/or business object of some sort?
On Thu, 27 Jan 2005 16:11:56 -, Kerry [EMAIL PROTECTED] wrote:
What if you grow hire a new developer? You may not want outsiders to
know how to use your app, but there's no reason to
I could see the genericDAO scheme working if there was an argument on
the create method that required an object that implemented a
fictitious interface dictating that that it only took objects with a
getConfig() method.
okay im not really getting it.
the 2 scenarios are:
1. function has
Inline comments :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Ben Rogers
Sent: Thursday, January 27, 2005 9:25 AM
To: cfcdev@cfczone.org
Subject: RE: [CFCDev] Composition and SQL
There are some relatively simple ways to solve that. Fowler addresses
Option 1 means that you must write and maintain all
insert/select/update/delete SQL for your app?
Is that correct?
Yes. Into every life a little SQL must fall. I think you'd find,
however, that writing SQL for individual types to be persisted is less
work than cooking a metadata scheme that
Just a quick note to the list that I plan to move the CFCZone.org web site
to our new host, CFXHosting, this weekend. I'm planning to implement the
move somewhere in the window of 6-10pm Mountain (Arizona) time, depending
on how happy hour works out ;-) I'll try to minimize any downtime of the
hmm give this man a candy bar...
http://jroller.com/page/nweber/20050121#my_superplatform_vision
hehe this quote is classic...
The current situation for developing a web application is to glue a web
framework like Struts together with an ORM and then write huge amounts of
trivial but custom
14 matches
Mail list logo
