I’ve been buried by work lately, as the current project is in a serious time crunch. During this time, however, I’ve been reflecting on what a huge difference the workplace can be depending on what type of people are managing the process.
In my last job, my manager, the CTO, managed people by asserting the following traits:
Some good traits, some bad traits.
In my current job, things are handled differently. Again there are good and bad issues.
Weighing the pros and cons of each company, I’d much rather work for my current employer even though there are days I’d easily strangle people with a smile on my face, and then go have a great night’s sleep. However, the number of days that I leave content and even happy are far greater. Different strokes for different folks. There are people who have been working at my previous employer for over 7 years and have no plans on leaving.
As to the title of the post, I’ve often wondered what leads a person to believe that humiliation of the staff is a truly effective way to motivate them.
Powered by ScribeFire.
Straight “out of the box” error handling functionality in the jQuery version of ajaxCFC is solid, but basic. The attribute useDefaultErrorHandler defaults to false, and when an error is thrown up to ajaxCFC, two things are done.
The error is caught and handled in the __initialize_AjaxCFC() function which, in turn fires the alertError() method. If the debug setting is enabled, then the error is logged by ajaxCFC, otherwise a Javascript alert is produced.
if (jQuery.AjaxCFCHelper.getDebug() == true) {
log.error('Type: #jsStringFormat(arguments.objError.type)#, Message: #jsStringFormat(arguments.objError.message)#, File: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
} else {
alert('An error has occurred:\nMessage: #jsStringFormat(arguments.objError.message)#\nFile: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
}
However, in my applications, I prefer the user not see generic, unintelligible error message in Javascript alerts, so I set useDefaultErrorHandler to false when making ajaxCFC calls. Then I can use the built-in success() and error() methods provided by the library. Here’s an example.
$.AjaxCFC({
url: "model/ajax/custom/package/Component.cfc",
useDefaultErrorHandler: false,
method: "method",
data: { 'argument':value, 'argument':value },
timeout:15000,
success: function(results) {
successfulMethodCall();
},
error: function(results) {
failedMethodCall();
}
});
However, I was still seeing the Javascript alert produced by ajaxCFC, so I added another condition to the alertError() method code. It checks to see if the useDefaultErrorHandler property was enabled, and if so, bypasses throwing up the alert or logging the message.
if (jQuery.AjaxCFCHelper.useDefaultErrorHandler == true) {
if (jQuery.AjaxCFCHelper.getDebug() == true) {
log.error('Type: #jsStringFormat(arguments.objError.type)#, Message: #jsStringFormat(arguments.objError.message)#, File: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
} else {
alert('An error has occurred:\nMessage: #jsStringFormat(arguments.objError.message)#\nFile: #jsStringFormat(arguments.objError.TagContext[1].TEMPLATE)#:#jsStringFormat(arguments.objError.TagContext[1].LINE)#');
}
}
Now I can handle any error with custom Javascript code inside the $.AjaxCFC() call, but what about keeping a history of errors? I always maintain a log of errors produced by my application, but I never use Javascript to do so, I use the
I needed a way to have built-in error handling accessible to any of my components that extended model.ajax.ajax. My solution was to add a method to the Ajax component that would accept two parameters – the name of the log file in which to log errors, and the cfcatch object. I could then log all of the attributes of the error with one simple call.
<cffunction name="logError" access="package" output="no" returntype="void">
<cfargument name="logFile" required="true" type="string">
<cfargument name="caughtError" required="true">
<cfloop collection="#arguments.caughtError#" item="errorKey">
<cfif isSimpleValue(arguments.caughtError[errorKey])>
<cflog file="#arguments.logFile#" type="error" text="#errorKey#: #arguments.caughtError[errorKey]#">
</cfif>
</cfloop>
<cfset throw(arguments.caughtError.type, arguments.caughtError.message, arguments.caughtError.detail, arguments.caughtError.errorCode, arguments.caughtError.extendedInfo)>
</cffunction>
I really wanted to go to MAX this year. There’s a lot of new tools that have either been released or are in development that I find exciting as an RIA developer. In lieu of going, I’ve been scouring the blogosphere for update from the attendees.
For those who haven’t heard about it yet, Thermo in currently in Adobe Labs, and is a design tool that will also create a workable application from that design. Definitely something I’m going to play around with.
Adobe also recently unveiled the Adobe Developer Connection. A central portal for resources for all their development tools.
This is going to be an amazing release, and this preview should be enough to convince you. I’m currently using the 1.1 release for an application, and I can’t wait to use some of the 2.0 feature in the future. For me, the Web Desktop is the most impressive.
http://extjs.com/blog/2007/09/06/ext-20-a-preview/