Phillip Senn wrote, On 2/19/2007 10:33 AM:
> Will I see a savings of time by the time I am done?
That's been the unspoken question for so many people.
I doubt the savings of time would be noticed by the time he finished,
but it would be evident when maintaining the code, I think. And, its not
just time-saving that comes into play here - we also should think about
the headache poor design can cause, and the inertia we have to overcome
when needing to work on something that was not designed well.
I wonder what the group has to say about that.
It used to be (back in the 80's) that you could cost justify an
expense if you could show a 3 year Return On Investment (ROI).
In other words, if a new piece of equipment paid for itself within 3
years, you could more than likely get it approved.
Taking that analogy into the time-save category, and recognizing that
we are now working on Internet time,
Q: What do you think should be a good ROI should be for spending your
time on a new technology?
This might be helpful in making the millions of little decisions that
I've been making all along.
I haven't ever looked at it like that. I just like to learn, so when
I've got the time, I try to pick up something new. More often, I don't
have time, but I'll be able to learn new things as a byproduct of the
particular project I'm working on. I would be interested though, if
someone did have a way to map the learning of new technology to ROI.
"If I create this shortcut, will it save the amount of time that it
took me to create it over the span of the next x years/months/weeks?"
That's what I'm working on now. But, it's sort of backward. "This stuff
took me all these years. A lot of it is not designed as well as it could
be, maintenance is a nightmare in some cases, and a lot of it could have
been extracted as reusable code." (from a lower level viewpoint than
just "message boards" or "login screens"). I've looked at it that way,
and decided I may as well do something about it.
"If I put business logic in CFCs…"
Well, one would have to do it correctly first =). But, I don't think
procedural apps have to be unmaintainable. You can screw up procedural
code just as easily as OO code - I think we've just come to think of
"procedural" as being "poorly designed." This doesn't have to be the
case. I think well-designed OO through CFCs still can offer more
benefits than well designed procedural code, and possibly enough to
justify looking at it from an ROI perspective. Certainly there is a lot
of literature and an almost an entire industry preaching the benefits of
OO over procedural code...
"If I learn this framework…"
What about just writing one? =)
-Sam
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of
*Jim Cassata
*Sent:* Saturday, February 17, 2007 11:29 AM
*To:* [email protected]
*Subject:* Re: [CFCDEV] CFC best practice
thanks Nando!
I have been looking at ModelGlue in order to get my brain around what
it actually is. I do not understand what a "framework" is and am
trying to get a grasp on what it is and how I will benefit.
Not sure of the benefits because:
1) My web app is already built consisting of 750 cfm files
2) I am the sole developer
I am saying not sure because that is the boat I am in. (which is
floating nicely) I just sunk two solid weeks of my life into CFEclipse
and am now seeing some benefit.
So, as I am going through my web app to put BL into CFCs, should I now
be recreating is as a new app in ModelGlue? Will I see a savings of
time by the time I am done or will it be like more of a rewrite of my app?
----- Original Message ----
From: Nando <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, February 16, 2007 8:47:12 PM
Subject: Re: [CFCDEV] CFC best practice
Jim,
I've been thinking about your post in the back of my mind for a few
days. I have a suggestion for you to think about. Try ModelGlue out.
MG, because of the way it's structured, throws you in the water so to
speak with CFC's. You use CFC's to do everything except the display .
And it's really not too difficult to learn.
What will probably happen is you'll soon be making your first design
"mistakes", which are similar to putting your shoes on the wrong feet,
or your shirt on backwards. And that's when you begin to learn
something valuable, because you then need to figure out how the shirt
or the shoes fit properly in your application design.
So the nice thing about MG is that it plops you in a world filled with
CFC's to begin with. At first, that might be foreign and a little
frustrating, but the MG QuickStart guide is really easy to follow and
that helps. Try it out with a simple, personal project first.
A disclaimer about Flex tho'. MG is for HTML apps with perhaps Flex
widgets. It becomes useless if your app is entirely Flex based. MG is
also appropriate if you have a Flex component alongside an HTML
component and they both share common services.
Nando
On 2/15/07, *Jim Cassata* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi all,
As I am moving my single tier CF app (hey, that was how the training
was done back then ;) to be multi-tier, I have a question re forms and
CFCs. In my app, I have a form.cfm page and the form action is the
formaction.cfm. The question I have is should I use the CFC as the
form action or use a cfinvoke from the formaction.cfm. I have seen a
how-to-do-this in livedocs but not a whether-I-should-do-this. It
seems that all things being equal I could do away with quite a few
formaction.cfm pages and consolidate into a few CFCs. Your thoughts?
Thanks,
Jim C
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com <http://www.katapultmedia.com>
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
<http://www.mail-archive.com/[email protected]>
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com <http://www.katapultmedia.com>
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
