Dick it wasn't meant to be elitist, it was a real question. I think
everyone agrees that good coding practices are essential. However everyone
that has come up with a reason not to use fusebox (including you) have only
delivered what appears to be ignorance of its present implementation. I have
not read Dave's monolithic response yet, and will do that next.
However,
...rather than distributing duplicate code among dsp, act and err
templates...
You know the whole point of fusebox is to reuse code right? If you are
duplicating code, you are not implementing fusebox correctly.
....The tradeoff is one somewhat larger module vs several smaller modules
requiring synchronized, concurrent changes....
What synchronized changes are you referring to, that would not have to be
made in your monolithic template? This is like the guy that said he didn't
use fusebox because it called index.cfm too many times. You would only call
index.cfm as many times as you would individual templates.
I really think you need to take a look at the fusedocs again. My cybercash
logic is slim and written in fusebox. Wherein none of my clients are
Amazon.com, none of them are Betty's Boutique either and I have never had
anyone call me and say "Our shopping cart doesn't work and its all because
its written in fusebox". Matter of fact I haven't ever had anyone tell me
that the cart doesn't work period. Most of these applications have multiple
fulfillment houses and handle cross fulfillment for back orders et al. You
cannot charge the credit card until the product ships, so you have to hit
your merchant processing company twice (once for the approval/hold and once
to bill when the product ships). Why write that code twice? What you are
suggesting means that you do. You write it once in your monolithic display
page and once in your backend charge process. I just include the action
page twice. Once the logic is written (or called as a servlet) on a
template, fusebox allows you to just "plug it in". If yours turned out
ugly, do we think it is because you were not properly using the methodology?
So far it seems it could be the case. If you are really having problems with
cybercash, use paymentnet instead, those guys are never down.
I can arguably build a better widget using pure JAVA or Broadvision (I have
yet to walk down the weblogic road extensively), and there are things I like
about ASP, but I choose CF/EJB because among other things its light weight,
affordable and allows rapid development. The cases you all are making for
not using fusebox are not disimilar to the arguments against using CF. Some
ASP developer might say "You can't do this in CF" and my response would be
"Yes, you can do that in CF, you however are not used to doing it in CF so
to you it looks like you cannot". You are saying "I don't use fusebox
because you can't do this", and I am saying "Yes you can". It is simply a
framework methodology.
I only do contract work and have had to program using everything from
Viant's methods to fusebox. I have had a great deal of experience revamping
other developers' code and I have found it no easier than when the code is
written in fusebox. For me it works. If it doesn't work for you, great.
Well written logical code is well written logical code, it has nothing to do
with the framework you wrap it in. So to make erroneous statements that
some logic cannot be implemented or would suffer using fusebox is
fallacious. Anything you can do in any methodology can be implemented in
another. I have yet to find any business logic that suffered because it was
written in fusebox. If you have a good framework methodology, use it. I
use fusebox because it allows me to pump out applications fast, subcontract
work and spend most of my time on the beach with my kids or returning
emails like this.
>It is not a panacea... I refuse to bastardize system design or
implementation to conform to *any* arbitrary >standar(d).
Fusebox is not an arbitrary standard and to call it such demeans the time
and effort Steve, Gabe, Hall, Nat et al have put into developing it. If you
don't like it, don't use it, but there are a whole bunch of people that are
trying very hard to develop something useful to this community. I am still
waiting for the example of this mythic system bastardization which has
escaped me in my development career.
Sean Renet
----- Original Message -----
From: "Dick Applebaum" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 8:38 PM
Subject: Re: [CF-Talk] RE: Ben Forta, I call on thee (was: What is Fusebox)
> Sean
>
> You do have a point, I have not used the Fusebox technique in a
> while... I imagine there new techniques.
>
> At 12:34 PM -0700 9/19/00, Sean Renet wrote:
> >Dick, I think you need to spend a bit of time looking at new techniques
that
> >are being used in fusebox. I have similar logic solutions in fusebox,
mine
> >are just more readable.
> >
> >I generally use the javascript for form validation, and the same
fuseaction
> >with the same forms to validate any validation that is logic related.
This
> >makes my display templates smaller therefore easier to read and any
> >validation logic beyond form validation is done in a act_ template. What
> >you are doing makes one monolithic template which would be hard to read
by
> >another developer.
>
> Not necessarily. For some of us, it is easier to understand and
> maintain a component, such as a registration form, if all the logic
> is concisely coded in a single template... rather than distributing
> duplicate code among dsp, act and err templates.
>
> The tradeoff is one somewhat larger module vs several smaller modules
> requiring synchronized, concurrent changes,
>
>
> >
> >With your cybercash scenario, all you need is a switch to handle the
error
> >or response from cybercash and cflocation changing the fuseaction. On a
> >timeout, you simply decide how many times you want to try the request and
> >reset the counter on each attempt then cflocation them to whatever logic
you
> >have for cybercash being down.
>
> No, It is not quite that simple... there is the rather common
> situation where Cybercash is busy or experiencing intermittent
> problems (yo-yoing up and down)
>
> It is not as simple as try authorization n times then mark cybercash
> as down... what if the customer has entered a 45 line-item order?
>
> Every few hours you will get a Cybercash request that times out,
> (maybe after a few retries)
>
> when you retry again, you get the response, it says that the order
> was already approved. Early versions of the Cybercash tag would not
> return any additional information (the approval code, AVS response,
> etc).
>
> So, you then had to invoke CashRegister login, then 2 levels of query
> with CFHTTP tags.
>
> Now, you might encounter additional (different errors) justtrying to
> co,plete the transaction.
>
> I did this with a Fusebox application... and it was pretty ugly.
>
> BTW, I *was* able to complete about 98% of the error recoveries,
> with no imposition (other than delays) on the customer.
>
> >
> >e.g..,
> >
> ><cflocation url="index.cfm?fuseaction=whatever">
> >
> >So far all of the people that are not fans of fusebox simply do not know
how
> >to use it and have spent no time reading the documentation or researching
> >its implementation. Do any of you have any real problems with fusebox?
>
> I resent this comment... it is elitist.
>
> I really don't want to get into a pissing contest... here is what I think:
>
> Fusebox is a good discipline to address *some* problems... if it fits, use
it.
>
> It is not a panacea... I refuse to bastardize system design or
> implementation to conform to *any* arbitrary standar.
>
> That's MNSHO
>
> Dick
>
>
>
>
>
>
>
> I strongly disagree. I use Fuse box
> --------------------------------------------------------------------------
----
> Archives: http://www.mail-archive.com/[email protected]/
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
>
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
