DevNotes On AJAX

As a long-time user of the FLiP methodology, there have been many times where I've created a prototype and used Hal Helms' DevNotes as a plonk-and-play way of capturing clients' thoughts and feedback.

It's a nifty little tool that does the job it sets out to do - but since it was released way back when, teh intarweb has moved on, and I've had a few niggly things that I had to work around when using it :

• it's rendered using "old-school" HTML, with things like FONT tags


• sometimes you can get conflicts between the DevNotes form submissions and parameters that the containing prototype app requires


• the dependency on cfx_make_tree.dll didn't play nicely with a non-Windows OS

So, while noodling around over the weekend recently, I decided to give it a bit of a facelift. One thing led to another, and it ended up as a pretty major update. So laydeez and gennullmun, allow me to present....(drum roll)

DevNotes On AJAX!

Main Changes:

• Removed dependence on CFX_Make_Tree.dll,
  replaced with udfMakeTree.cfm from cflib.org, by Michael Dinowitz
• Ported to be based on Ajax requests,
  de-coupling the DevNotes requests from the Prototype page requests, and allowing people to stay on the same Prototype page while adding notes
• Added RSS syndication of notes.
  
• Prefixed all request variables and JS functions with DEVNOTES
  to prevent any potential conflicts with the containing app
  Required parameters in the containing app are now:
  
// these fields required for DevNotes
request.DEVNOTES.devAppName = "UniqueAppname";
request.DEVNOTES.attributeToKeyOn = "page";
request.DEVNOTES.DevNotesDSN = "YourDSNName";
request.DEVNOTES.devnotesRSSTitle = "Title for the RSS feed";
request.DEVNOTES.DevNotesRSSDescription = "Description for the RSS feed";

  
• Updated HTML to be more semantic and standards-based.
  Admittedly it might not be 100% XHTML-compliant, but I don't really have time to check it on that - be my guest...
• Introduced CSS styling
  and grayscale mini icons from Brand Spanking New
• Re-factored the code into a fusebox3-stylee app structure.

Example usage:

Extract the archive into a subfolder called "DevNotes" under the root of your prototype app.

Make sure that the following variables are set up somewhere in your app - fbx_settings.cfm is usually the best place :


// these fields required for DevNotes
request.DEVNOTES.devAppName = "UniqueAppname";
request.DEVNOTES.attributeToKeyOn = "page";
request.DEVNOTES.DevNotesDSN = "YourDSNName";
request.DEVNOTES.devnotesRSSTitle = "Title for the RSS feed";
request.DEVNOTES.DevNotesRSSDescription = "Description for the RSS feed";


Then in your prototype's LAYOUT file, just add
<cfinclude template="../DevNotes/DevNotes.cfm" />
(replace the path as necessary)

NOTE: don't put this in OnRequestEnd.cfm, as it will get triggered for each AJAX request and land you in an infinite recursive loop! The layout file is the best place for it, as it's display-generating code.

Usual usage policy : you can do what you like with this code, so long as
a) you maintain the attribution comments
b) you accept that it's provided entirely as-is, with no warranty of any sort
c) you don't violate any terms in the other code that it includes (see credits within the code)
and most importantly
d) you don't have too much of a go at me for not commenting it particularly well!


Enjoy !

DevNotes On AJAX

In Defence Of Hungarian Notation

I started typing a comment on Pete Bell's post Why Not Hungarian, but it got a bit too long so I've put my two-penn'orth here.

Hungarian notation, for me, can be very useful, but maybe not in the form that's most commonly understood. I've heard the argument that the original intent behind Hungarian notation was to declare what KIND OF THING a variable is - but this got mistranslated into what TYPE a variable is, and the two are not the same -

For instance, in the last big CF project I did, I took to declaring strings that contained markup with a "htm" prefix, and strings that may have character codes - such as from textarea input - with a "raw" prefix. Similarly URL-encoded strings get an "enc" prefix. They're all strings, and traditional Hungarian notation might give them all the same prefix - but if you do it this way, as soon as you started typing a line like:

<cfset htmContentForDisplay = rawInput />

you immediately know that something is wrong. The variable prefixes themselves make you think "Hmm - that's not going to work.... I need to do some intermediate processing to convert the formats there"

In a strongly-typed, pre-compiled language like Java or C++, then Hungarian notation can just get in the way - you've got the compiler as a type-safety net, and anyone who's ever tried to do anything meaningful with MFC will certainly testify to the horrors of things like "lpszhwndmyWindowHandle". But I think that in loosely-typed languages such as CF, Hungarian notation has it's place if you use it properly - remember, "a Hungarian is the only man who can follow you into a revolving door and come out first" :-)