consutants bag of tricks

nipper

OK, I am curious and would be interested in what other people post. As an independent I tend to write things and then start to clean them up as I see that this is something that would be usful in mulitple engagements. I know the first WF emails started off as a consultant project.

So my idea of this thread is to MENTION/DESCRIBE tools that may be of interest to other people. I am not suggesting posting scripts/librabries/applets/etc that you have spent a bunch of time working on and giving away for free. Just giving people ideas of what they may want to write IMHO would be of interest.

I tend to do a lot of TS/Forms Publisher, so I get a zip of templatedata and load it on my own VM, many of the utilities are to help that.

So here are a number of things I use over mulitple projects:

- JS library for commonly used functions: esp call servers.
- templating related Perl modules (talked about that at length at GearUp)
- Script to fix EAs in any templatedata folder
- Script to read templatedata and generate templating.cfg
- Script to read DCR names (save in a hash) and then read all HTML files, looking for matches and attaching TST EAs to the generated files (this is a work in progress and somewhat manual still)
- GenerateContent workflow step
- workflow review timeout/escalation

Anyone else interested in bragging about what you write ?

jbonifaci

Well, I'm not a "consutant" any more, but if I were to go down that path again, I have some "tricks" I could reuse. Some of the ones I am more proud of:

* I have an inline DCT creator that creates the DCT XML based on a config file that corresponds to the content type. The config file can specify 1 to many related config files, allowing componentized creation of DCTs and therefor reuse. It also is configured in such a way that each config component you load has a corresponding javascript file that is loaded that knows how to initialize and handle the items in that config file. I mainly use components as tabs and when I create new DCTs, I can include 3 or 4 common tabs and only have to develop the config and javascript for the tab(s) specific to the new content type. (On a side note, the inline also outputs the javascript to load all of the values for all of the drop down values for all items in each of the config files to a global codes javascript object. This is somewhat specific to to my current implementation, as it is loading these values from a proprietary database, but could be modified for other implementations.)
* I have an extensive formapi library that I touched on only the tip of at my GearUp presentation a few years ago. The key to the library is AdvancedEventRegistry.js, which I made available after my presentation. Without being able to pass parameters to event handler functions and without being able to call multiple functions for an event handler, my generic formapi library would not be nearly as large as it is. I can usually create a form with only an initialize function that does all of the registrations and needs no other content type specific functions. If there is something I do need, I usually try to create a generic function for it that can be reused in the future.
* I have a generic external task script that is called by every external task which takes options for which functions that need to be called. The wrapper script handles all of the logic for retrieving task objects, job objects and creating a log object that it passes to functions that are tied to the options passed in. If any of the option functions called return an error, the workflow transitions to the error successorset, otherwise it transitions to the success successorset. It is also configured to allow the functions to be able to return the name of the successorset they want to transition to, if it needs to be something other than the default error or success. Adding additional options simply requires that the module be included and a one line registration mapping the option name to it's function in the external task script. This allows a single external task, instead of chaining many. It allows the functions to simply do what they need to do, instead of each one having to worry about retrieving objects and transitioning. I also of course have a library of generic functions that can be called by this.
* I have my own template based email script (called from the aforementioned external task script via the "-sendEmail" option) that is similar to the iwov one that handles most of the iwov tags (wichever ones I bothered to implement). The main reason for this is to handle complex to and from email address logic (specified in task variables). I have an engine for this that, although complicated, is easy to use. (There is also some logic built in for timeout emails and changing the email template if the max number of timeouts has been reached and no more emails will be sent).

I have a bunch of other stuff too, but these are the most useful to me.

~Jeff