Lately, I have started working on the OpenXFDL project again, concentrating efforts in making a C++ application with WX Widgets that can compile for Windows, Mac, and Linux. Getting frustrated with libxml2 and wanting to learn more of xpath queries, I decided to make a XFDL reader in PHP. This can be applied easily as browser/e-mail plugins to view XFDL forms without the need of an external viewer. I’ve been bad about posting but I’ll work to add more to this blog soon. For now, here is a sight to try it out with. Unlike previous stuff, you can do a straight XFDL form instead of converting to XML first. Try it out!
The other day I posted some code with PHP method for compressing XFDL files. I was unfamiliar with PHP’s chunk_split function, so I googled it and came up with this reference. I then wrote the appropriate code in Python which is a quick script like this:
#!/usr/bin/env python #string chunk_split ( string body [, int $chunklen = 76 [, string $end = "\r\n" ]] ) def chunk_split(body,chunklen=76,end="\r\n"): data = "" for i in range(0,len(body),chunklen): data += body[i:min(i+chunklen,len(body))] + end return data
You can see this code in action through this output:
zds@CF55 ~/Desktop $ python Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> from chunk import * >>> test = """Hello, how are you today? This is a test of my python interpreta tion of the PHP function, chunk_split(). It should take this one line of writi ng and split it by 76 characters and add a DOS compatible line end (e.g. \r\n) by default. I've done my best to have code as close as possible to the PHP fun ction. This was done in an attempt to work out a method of compression XFDL fi les. I've found this function to work but still need to figure out a way to ru n a compatible gzip method to PHP's gzencode from Python.""" >>> chunk_split(test) "Hello, how are you today? This is a test of my python interpretation of the\r\ n PHP function, chunk_split(). It should take this one line of writing and s\r\ nplit it by 76 characters and add a DOS compatible line end (e.g. \r\n) by defa\ r\nult. I've done my best to have code as close as possible to the PHP functio\ r\nn. This was done in an attempt to work out a method of compression XFDL fil\ r\nes. I've found this function to work but still need to figure out a way to \ r\nrun a compatible gzip method to PHP's gzencode from Python.\r\n" >>>
It appears to work! This still doesn’t fix my compression problems with the XFDL files though. It would appear that gzencode does the correct compression, now I just need to find a way to do the same compression in Python. The GZipFile methods do not output the same as gzenecode() in PHP.
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:
- Print Settings
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 <itemlocation> <ae> <ae>absolute</ae> -- style='position:absolute' <ae>y</ae> <ae>x</ae> </ae> <ae> <ae>extent</ae> -- dimensions <ae>l</ae> <ae>w</ae> </ae> <value>THIS IS WHAT NEEDS EDITTING!</value> - input, no border <broderwidth>0</broderwidth> --> style <fontinfo> --> style <ae>type</ae> <ae>size</ae> <ae>attribute</ae> </fontinfo> <justify>center</justify> --> style <scrollhoriz>wordwrap</scrollhoriz> <scrollvert>fixed</scrollvert> <next>TO</next> -> form taborder <previous>DATE_A</previous> -> form taborder <acclabel>lorum ipsum</acclabel> <format> <ae>string</ae> --> set form input type <ae>optional</ae> --> validation check <length> <ae>0</ae> vert <ae>18</ae> horiz </length> </format> </itemlocation> </field>
Next part, check boxes. Nothing too scary here. Much the same as above.<check sid=""> same <itemlocation></itemlocation> same <value>on|off</value> <fontinfo></fontinfo> same <next></next> same <previous></previous> same <acclabel></acclabel> same </check>
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 <value>TEXT</value> <linespacing>1</linespacing> OPITONAL <fontinfo></fontinfo> same <fontcolor>black</fontcolor> <format></format> same </label>
Lines, not too bad… will just be a simple parsing the xml to putting them on the page.<line sid=""> same <itemlocation></itemlocation>same </line>
Buttons! These would be easy but they will associate with signatures.<button sid=""> same <itemlocation></itemlocation> same <value compute="">FROM CERT</value> <type>signature|</type> <vfd_signmode>custom</vfd_signmode> <printvisible compute="">on|off</printvisible> <signformat>???WTF???</signformat> <signature>FOR BINDINGS</signature> <signer>FROM CERT</signer> <custom:onClick>function</custom:onClick> <signoptions> <ae>omit</ae> <ae>triggeritem</ae> <ae>coordinates</ae> <ae>ufv_settings</ae> </signoptions> <vfd_group>??</vfd_group> <format></format> same <previous></previous> same <next></next> same <image>FROM CERT?</image> <signatureimage>FROM CERT?</signatureimage> <signitemrefs> <ae>LOCK BINDS</ae> -- USE FOR VALIDATION </signitemrefs> </button>
Not even touching signatures until I get the parsing scheme in place!<signature> WILL DO LATER </signature>
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> </data>
Do I really need the toolbar if I’m not using it’s functions?<toolbar sid="TOOLBAR"> <bgcolor> <ae>gray60</ae> </bgcolor> </toolbar>
Is IBM so dense they can’t find a new name for the toolbar tags instead of reusing label?<label sid="TOP"> <itemlocation> <ae> <ae>within</ae> <ae>TOOLBAR</ae> </ae> <ae> <ae>absolute</ae> <ae>0</ae> <ae>0</ae> </ae> </itemlocation> <image>PAGE1.ArmyLogoTop</image> <imagemode>clip</imagemode> -- style <active>off</active> </label>
I won’t complain about this one! Seems pretty simple, just like lines…<spacer sid=""> same <itemlocation></itemlocation> same </spacer>
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.
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.