dispatchToECF?

[Aaron Madsen]

Lee,
The more accustomed to QuickConnect I become, the more interested I am
in error control stacks. It is really useful to be able to trigger them
when validation fails. However, I find that sometimes I need to trigger
them because of an error state in a BCF (perhaps because my
ServerAccessObject or DataAccessObject getData() call returned bad
information or an error.) Usually I just end up terminating the command
stack and triggering another on a case by case basis. I think I have
also seen dispatchToECF() called directly from a BCF in some of the
database examples, which makes sense. This would allow me to specify an
error condition/message as a parameter for the error control stack. Is
this the preferred usage in this case?

The code block at the heart of requestHandler() that triggers the
error control stack for ValCF failures look something like this
(QuickConnect.js, lines 90-105):
if(aCmd != null){
if(dispatchToValCF(aCmd, paramArray)){
try{
var data = dispatchToBCF(aCmd, paramArray, callBackData);
if(data != 'stop'){
dispatchToVCF(aCmd, data, paramArray);
}
}
catch(err){
logError(err);
}
}
else{
dispatchToECF(aCmd, 'validation failed');
}
}

I am curious if there would be value in adding a dispatchToECF call to
the catch block, so it looked like:
if(aCmd != null){
if(dispatchToValCF(aCmd, paramArray)){
try{
var data = dispatchToBCF(aCmd, paramArray, callBackData);
if(data != 'stop'){
dispatchToVCF(aCmd, data, paramArray);
}
}
catch(err){
logError(err);
dispatchToECF(aCmd, 'View Control Failure',
paramArray, callBackData, err);
}
}
else{
dispatchToECF(aCmd, 'Validation Failed', paramArray);
}
}

and modifying dispatchToBCF()'s runFailure catch block
from(QuickConnect.js, lines 247-250):
catch(err){
logError(err);
dispatchToECF('runFailure', err.message);
}
to:
catch(err){
logError(err);
dispatchToECF('runFailure', err.message); // run the
existing 'runFailure' stack that generates handy error messages.
dispatchToECF(aCmd, 'Run Failure', paramArray,
callBackData, err);
}

These changes would cause the Error Control Stack to be triggered any
time there was an error, with sufficient context to be able to react
appropriately. It could get messy determining which error condition the
stack should be responding to, which is one reason I still tend to like
triggering another command stack, but I think it makes more sense than
having some error control handed to an Error Control Stack by
QuickConnect (Validation Failures), some handled partially by
QuickConnect in a speciallized command stack and/or manually handed to
an Error Control Stack by the programmer (Run Failures), and some barely
handled at all (View Control Failures.)

I'm going to try these changes out - see how they work for me. There are
likely some backward compatibility issues to consider here as well. Let
me know your thoughts.

Thanks,
Aaron

[Barney Cit]

Aaron,

The code you are referencing is old and still exists in the framework for backward compatibility only.

The preferred methodology is to call handleError from within the stack. This way the error can be most effectively handled by the error control stack.

Lee

Sent from my iPad

> --
> You received this message because you are subscribed to the Google Groups "QuickConnect" group.
> To post to this group, send email to quickconn...@googlegroups.com.
> To unsubscribe from this group, send email to quickconnectiPh...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/quickconnectiPhone?hl=en.
>

[Barney Cit]

Aaron,

Additional:

handleError can be called from within any control function. It could be a VCF, BCF, or ValCF.

Lee

Sent from my iPad

On Nov 19, 2011, at 1:44 PM, Aaron Madsen <ama...@affinityamp.com> wrote: