views:

32

answers:

2

Hi all, this is my first stack overflow, and it's a complex one. Sorry.

My task is to generate custom documents from a basic template plus some XML without having a custom form design element for each case.

Here's the whole picture:

  • We are building a Lotus Notes (client, not web) application for world-wide application access control; the scope is something like 400.000 users being able to request access to any of 1000+ applications. Each application needs its own request form -- different number of approvers, various info required, that sort of thing.
  • We simply can't have a thousand forms in a database (one per application), and anyway their maintenance really needs to be pushed from the developers to the application owners.
  • So instead of custom forms, we'd like to create a generic "template" form that stores a block of basic fields, but then allows application owners to define another block of fields dynamically -- "I want a mandatory plain-text field named 'Name' here, and then a date field named 'Due' here that must be later than today's date, and then ...". I hope this makes sense (if not, think of it as a generic questionnaire application).
  • I pretty much have the structure in place for designing the dynamic fields (form builder GUI -> XML-encoded data -> pre-rendered DXL for injecting into a form), including mark-up for field types, value options, and rudimentary field validation instructions.

My problem is generating a document with this dynamic content injected at the proper location (without needing a custom form design element for each case).

  • Doing the dynamic content via HTML is out. The Notes client web rendering is simply way too poor, and it would be quite a challenge to implement things like field validation instructions, date selectors, and name look-ups.
  • DXL, on the other hand, would allow us to use native Notes fields and code.
    • As a tech demo, I've managed to implement a custom form generator that injects the pre-rendered DXL for the dynamic content into a base form; but as I said, we don't want a ton of custom form design elements.
    • I've tried to implement a way to create a document with the "store form in document" flag set, but once I've created the document from the base form, I can't get DXL access to the stored form design, and so I can't inject my dynamic content.

I know this is not something Notes was ever intended to do. Has anyone ever tried something like it (and gotten away with it)?

Thanks for reading this far.

With a boatload of thanks in advance,

Jan Gundtofte-Bruun

A: 

I don't really have an answer for you, but some thoughts:

I know you mention that the app must be for Notes client and not web - is that an absolute? A Domino web app would give the flexibility to do what you need with less effort than forcing this into the Notes client. (Perhaps a hybrid app - where request forms are filled in via a browser, but the reporting / workflow is done via Notes clients?)

Assuming that is an absolute, then I would revisit the DXL option - yes, you may end up with 1,000+ forms (or, better, sub-forms) in the database, but is that really a problem? I don't know of any upper limit on number of forms (either defined or practical). And, you wouldn't be "maintaining" these (sub)forms manually - your code would just detect the change to a configuration document, and then rebuild the appropriate form note.

To limit the actual number of design elements, perhaps you could implement a "template" concept - so multiple "applications" in your system could use the same access request "template".

Ed Schembor
Thanks for the prompt answer! We have our (complex) reasons for why we'd prefer to do it natively rather than in a browser, although we probably _could_ do that if we had to.I can't seem to find any documentation for why having 1.000 subforms would be a bad idea -- I simply took the architect's word for it. How embarrassing. I'll investigate!I'm already knee-deep in DXL. :-) The application needs to be self-modifying in order to programmatically maintain subforms, so _something_ would have to have Developer access. Selling _that one_ to the Business Controls folks might be tricky.
KlaymenDK
A: 

I ended up doing it a bit differently.

I will still use the "store form in document" option to make sure that each submitted request can stand alone; but "request" documents will be based on hundreds/thousands of individual forms (yes, that's thousands; research and testing suggests it shouldn't be a performance issue). These many forms, then, will be programmatically generated.

I'm setting it up so that "template authors" can create "request templates", which are normal documents with a block of xml in them. A background agent then takes all these documents and processes each block of xml, and a base form, into new custom forms. These custom forms are presented to users to create their "request" documents from.

KlaymenDK