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.
