Tag Archives: Web Development


So I have now made a front page to upload a CSV file and an XFDL file for this XFDL web application. Nothing is more surprising than being a few short steps from having a working prototype to discover you’ve made a grave error. Here’s my mistake. I used python’s xml.dom.minidom module to parse and edit the file in it’s XML form. But when saving it back, it becomes obvious that the encoding causes some minor problems, but the major problem comes in the form for it’s saved state. Where the XFDL file will have a set of tabs, the minidom would correct these to read just which then is not able to be read by Lotus Forms Viewer or PureEdge! I’ll be frantically rewriting my parsing in other modules tonight to find one that is compatible in it’s write method!

XFDL Viewer Update…

As I dig through miles of XML, I realize I have not posted lately. I’ve been a bit busy meeting the May 15th deadline for my project. But here’s a quick update. First, don’t forget to view the update viewer. It’s not pretty, but it works to the point I’ve set it. I’ve changed from PHP to using Python CGI (a language I’m more comfortable with) and I’ve done what took two weeks in two days. Too bad this wasn’t thought of before!! Anyhow, I figured I’d pass along this bit of code from Neil Funk that shows a better method for decompression of an XFDL in Python:

from base64 import *
import zlib

inp = open('example.xfdl','rb').read()
out = open('example.xml,'wb')

magic = inp.splitlines()[0]
data   = inp.split(magic)

# THE TRICKY PART -- Look to the python manual for explanation.
wbits = 15+32
newData = zlib.decompress(b64decode(data),wbits)


And drumroll please, for Chris Hutton contributed this PHP code for recompressing an XFDL from XML.  I’m working to translate this to Python, but for the time being, an XML with an XFDL extension works.

// Export XML, gzip, and base64 encode. Append XFDL header information and output to user.
// XML is the raw data to be saved.
$newxml = $xml->asXML();
// chunk_split is new to me!
$output = chunk_split(base64_encode(gzencode($newxml)));
// Add the header!
$output = "application/vnd.xfdl;content-encoding=\"base64-gzip\"\n". $output;

header("Content-disposition: attachment; filename=\"{$filename}\"");
header("Content-type: application/vnd.xfdl");

echo $output;

So thank you all for your contributions!  I’ll try to keep this blog more up-to-date.

XFDL Viewer – Good and Bad.

I used to think of myself as a decent coder, but this XFDL project is a monster.  Particularly with the parsing schemes.  Let alone the May 15th suspense on the project!!  Oh well, if it doesn’t get done, I’m still working on it…  So I broke apart the XML and just to give a taste of the parsing for this, here’s my notes:

Mind you, I’m skipping the globals but here what needs to be parsed from there:

  • Title
  • Version
  • Fontinfo
  • Bgcolor
  • Print Settings
  • Bindings

This first block is the “field” form.  This is the main part to parse because this is where all values except checks and signatures will go.

<field sid="TO"> --> sid == div id
			<ae>absolute</ae> -- style='position:absolute'
			<ae>extent</ae> -- dimensions
		<value>THIS IS WHAT NEEDS EDITTING!</value> - input, no border
		<broderwidth>0</broderwidth> --> style
		<fontinfo> --> style
		<justify>center</justify> --> style
		<next>TO</next> -> form taborder
		<previous>DATE_A</previous> -> form taborder
		<acclabel>lorum ipsum</acclabel>
			<ae>string</ae> --> set form input type
			<ae>optional</ae> --> validation check
				<ae>0</ae> vert
				<ae>18</ae> horiz

Next part, check boxes.  Nothing too scary here.  Much the same as above.

<check sid=""> same
	<itemlocation></itemlocation> same
	<fontinfo></fontinfo> same
	<next></next> same
	<previous></previous> same
	<acclabel></acclabel> same

Here we get complicated.  Nothing bad about the labels, except there form uses labels for definitions at the end and you’ll see it later where it is reused for a new purpose.  This could pose a good challenge!

<label sid=""> same
	<itemlocation></itemlocation> same
	<linespacing>1</linespacing> OPITONAL
	<fontinfo></fontinfo> same
	<format></format> same

Lines, not too bad… will just be a simple parsing the xml to putting them on the page.

<line sid=""> same

Buttons!  These would be easy but they will associate with signatures.

<button sid=""> same
	<itemlocation></itemlocation> same
	<value compute="">FROM CERT</value>
	<printvisible compute="">on|off</printvisible>
	<signature>FOR BINDINGS</signature>
	<signer>FROM CERT</signer>
	<format></format> same
	<previous></previous> same
	<next></next> same
	<image>FROM CERT?</image>
	<signatureimage>FROM CERT?</signatureimage>

Not even touching signatures until I get the parsing scheme in place!


Data will be easy enough, just needs to be decoded and displayed.  Whew… may need to save the files to the server to display but I think HTML can handle an image from data.

<data sid=""> relates to signatures & images
	<filename></filename> -- image (optional)
	<mimedata encoding="base64-gzip"></mimedata>

Do I really need the toolbar if I’m not using it’s functions?

<toolbar sid="TOOLBAR">

Is IBM so dense they can’t find a new name for the toolbar tags instead of reusing label?

<label sid="TOP">
	<imagemode>clip</imagemode> -- style

I won’t complain about this one!  Seems pretty simple, just like lines…

<spacer sid=""> same
	<itemlocation></itemlocation> same

So keep watching the blog… I’ll post more when I figure out how to handle all this data.  And this all needs to be cycled per page to output to the browser… yuck.

XFDL Viewer

The scope of the “Apps 4 the Army” competition that I am making my XFDL Viewer for is to use web apps.  So I did a quick change to PHP and read up and got a framework setup.  The idea is to be able to import the XFDL file and then parse the resulting XML to input values, either on a single form or by batch through an uploaded database.

The framework is complete and I’m pretty happy with the results as I’ve done much more application programming than web development, but PHP isn’t too bad.  After getting the frame work together, I started to work on parsing.  I mistakenly uploaded a XFDL file rather than the decompressed XML and I found something remarkable.  PHP’s SimpleXML apparently can decompress the XFDL file!! This takes out a very complicated step of my project!!!  I’m still working to figure out why the recompression does not produce the same output but that may not be a problem with the web interface.  Stay tuned for more updates.

Custom Brush for SyntaxHighlighter Evolved

Okay, before I get started let me just say that I realize there are several already set-up plugins for the WordPress Plugin, SyntaxHighlighter Evolved to include a brush for the *.batch language.  Also, there is a great article by the Plugin’s author that will guide you through developing a brush.  The reason I am posting mine is to pass a long a few things that went unsaid for the less experienced WordPress Plugin developer, but let me just say that this was much easier both in the plugin development and brush development than I thought it would be.  The reason I made my own brush, it’s just more fun to make my own!

Now, that being said, here we go!   My post for “Violating IT Policy” included a batch script for Cygwin to be portable.  since there was no brush in SyntaxHighlighter Evolved To develop a brush, you will need to set-up a new plugin for word press.  The plugin will be adopted by SyntaxHighlighter Evolved as you will see in a moment.  The structure for this plugin will be:

<root folder>/wp-content/plugins/
                        /plugins/<javascript brush>.js
                        /plugins/<php plugin>.php

For the javascript brush, this does have some tricky elements. but I’ve commented what I’m doing below.

/** shBrushBatch.js **/
/* Declare a new brush with SyntaxHighlighter.brushes.<your name for the brush> */
SyntaxHighlighter.brushes.Batch = function()
	/* Declare words that you need highlighted */
	var variable = 'clear cls goto set';
	var constants = 'if or';

	/* This is the heart of your brush, you can use the *.
	/* SyntaxHighlighter.regexLib.* brushes when applicapble. */
	this.regexList = [
		/* You may notice that my comments are looking for a css that does not match. */
		/* I'll explain below the script. */
		// comments
		{ regex: /(^::|rem).*$/gmi,                             css: 'string'},
		// stings
		{ regex: SyntaxHighlighter.regexLib.doubleQuotedString, css: 'comments'},
		{ regex: SyntaxHighlighter.regexLib.singleQuotedString, css: 'comments'},
		{ regex: /echo.*$/gmi,                                  css: 'keyword'},
		// variables
		{ regex: /%w+\1/gmi,                                    css: 'keyword'},
		{ regex: /%\*|%%?~?[fdpnxsatz]*[0-9a-z]\b/gmi,          css: 'keyword'},
		// clear cls keywords
		{ regex: new RegExp(this.getKeywords(variable), 'gmi'), css: 'variable'},
		// if and key words
		{ regex: new RegExp(this.getKeywords(constants), 'gmi'),css: 'constants'},
		// labels
		{ regex: /^:.+$/gmi,                                    css: 'script'}

/* Create the highlighter object. */
SyntaxHighlighter.brushes.Batch.prototype = new SyntaxHighlighter.Highlighter();
/* Set the Aliases */
SyntaxHighlighter.brushes.Batch.aliases = ['bat','batch'];

So the reason that my css does not match the actual of what it is would be because the theme does not match my preference.  I perfer comments to be green, so since the string for the RDark format is green, I had to assing my comments to the string.  This was pretty confusing but the way I figured out my color scheme was simple enough.  In <root>/wp-content/plugins/syntaxhighlighter/styles/ you will find all of the css files to coordinate with the theme.  Half way down, you will see “Actual Syntax Highlighter Colors” and it is at this point that you will want to see what all of your options are.  Rather than converting #5CE63B to green, I went and made a sample script once my plugin was complete, I then went and set up a color tester like this, in place of my normal brush file:

/** shBrushBatch.js  - color test version **/
SyntaxHighlighter.brushes.Batch = function()
	/* 	set your wordpress to:
			... continue until the last keyword ...
			1 I dropped the correct closing in the example for formatting. */
	var string = 'string';
	var comments = 'comments';
	// ... continue to the last keyword ...
	var keyword = 'color3';

	this.regexList = [
		{ regex: new RegExp(this.getKeywords(string), 'gmi'), 	 css: 'string'},
		{ regex: new RegExp(this.getKeywords(comments), 'gmi'),  css: 'comments'},
		// ... continue to the last keyword ...
		{ regex: new RegExp(this.getKeywords(color3), 'gmi'), 	 css: 'color3'}

SyntaxHighlighter.brushes.Batch.prototype = new SyntaxHighlighter.Highlighter();
SyntaxHighlighter.brushes.Batch.aliases = ['bat','batch'];

After doing this and seeing the colors, I could then associate which color I wanted for which sets of syntax.

Now, onto making the plugin work.  Obviously, you’ll need both of these files to have any results.  What this does is when you activate this plugin (yes, it does show in your plugins) then SyntaxHighlighter adopts it.  This script is pretty standard from what I saw online and is almost exactly out of the author’s blog post.  The comments at the front are what will appear in your WordPress under Plugins.  I’ve kept the comments mostly the same as the author, as he is describing it better than I could.

Plugin Name: Batch Brush - SyntaxHighlighter Evolved
Descriptionn:  Adds support for the Batch language to SyntaxHighlighter Evolved.
Author: Zachary D. Skelton
Version: 1.0.2
Author URI: http://www.skeltonnetworks.com/

// SyntaxHighlighter doesn't do anything until early in the "init" hook.

// Tell SyntaxHighlighter about this new brush.

// Register the brush with WordPress.
function syntaxhighlighter_batch_regscript() {
// Add alternative names for your brush.
function syntaxhighlighter_batch_addlang($brushes) {
	$brushes['batch'] = 'batch';
	$brushes['bat'] = 'batch';

	return $brushes;

At this point you should be able to load your page.  If it cannot find the brush (you’ll get a dialog to let you know), you could replace plugins_url() in line 19 with a string of a direct path to the file, but there should be no need for it.  The most common reason for this is an error in your javascript brush, so make sure to check that before going to insane.  After this is all done, you may have problems seeing the results.  It took me 5 loads of the correct format before I saw the change, in that case, deactivate the plugin, clear the cache, change the plugin version number in line 6 and re-activate the plugin.  Should not need all of that but some browsers are fussy, and that takes care of any problem with the cache. As I said before, this is well documented and relatively easy to make.  You can see that I made my plugin only apply to my script but it would be easy to add more things to it.  I used a lot of my regex directly from this plugin because that is a skill I’m still working on.  But this was surprisingly simple, and you can find lots of good information on making plugins of your own.  It is surprisingly not too tough!