Should someone audit the and wonder why certain design anti-patterns were used, here's why:
While building this one page app paradigm, some design anti-patterns were useful, albeit their use would not be needed in refactoring the code, should that be needed:
The code is fairly monolithic for this first version of qfo_2g, mainly because I wasn't sure of the subtlety of dependencies early on. It turned out to save a bunch of development time in spite of the concern of dealing with variables outside of their intended use (and debugging), because large chunks of code was moved around, and redundancies could be eliminated through selective variable re-use.
The q-forms tag building procs (qf_*) used a somewhat unique design anti-pattern of consistent variables across all procs (within the paradigm) and unbroken lines of any length. Most all cases where consistent handling of data inputs, such as html tag attribute handling, could be identified with a simple editor search, and logic kept consistent throughout as features evolved.
The qf_* procs use an anti-pattern of sorts for passing parameters. As a result, parameters can be passed in a variable containing a list of name/value pairs, or as individual name/value list elements, or a combination of the two (mainly for flexibility for end-developer's needs). It seems more flexible and consistent than using {*}args argument expansion ( http://www.tcl.tk/man/tcl/TclCmd/Tcl.htm#M9 ), because with this anti-pattern there's no need to be concerned about list parsing in an unexpected way, such as can happen when lists contain some elements with spaces, or a string with spaces is inadvertently parsed into a list.
cheers,
Ben
