views:

27

answers:

1

Customer has asked for a system that involves a set of pdf forms, a web UI and some various functions (log-in, administration, permissions, the usual) and there's a few rubs I've identified and would like some feedback or maybe even completely different ideas on how to go about it. The main focus is the data contained within these forms. (don't think winforms, think forms you fill out and file)

First off, the pdf forms are uncontrollable in the sense they can. not. be. modified. I wrote a tool a while back (pdf-orm on codeplex) to take pdf forms (the fill-out kind) and turn them into objects so they're easier to work with in code and also to return to the pdf. So that part is handled rather nicely. The problem begins to come out of the data contained within the forms and how best to handle that. Granted, most of the field names are HORRIBLE (person1 for instance) but at least they're manageable.

These forms -will- change and MUST be changed in a reasonable time frame (ideally a few days) so maintainability/flexibility is a huge focus. Granted, not all the forms will change at the same time necessarily, but over the course of a few months to a few years, they will change. Even more concerning, the names/fields of those from the generated pdf can change -- no control over them (so I can't use the field-name-generated class as truth, there has to be a translator of some kind).

My first pass at this, I came up with "definition" classes as the heart, one per form with an interface (and use this interface for the viewmodel ... that comes later). These classes define what data is contained within the form. A translator would convert the definition class to the pdf class (handling the changes on the forms incase something goofy like person1 becomes PersonOne). Validation would be contained within those as well -- all of it testable.

I was then presented with a different idea, one that focuses strictly on the data itself. The data saved (xml format) would pass though an xslt or two to render the UI. This UI would be created by an admin tool (no developers) where the wiring of the pdf fields and the UI fields would be done, along with validation. I'm not real familiar with how this would work, if it can work at all, but I've been exploring it for the past few days with minimal success. We've really yet to answer the -how- on a lot of this approach.

I'm interested to hear other thoughts, opinions, directions.

A: 

Do these forms absolutely have to be in PDF in the browser or is InfoPath an option? E.g. what about a setup like http://www.bizsupportonline.net/browserforms/print-infopath-browser-form-pdf.htm

aponzani
the pdf's are the result (when they're done, they print it) and the driver (it defines what it looks like), but that COULD be an option. I'll look into it
jeriley