Complex form design in Sharepoint

Question

I'm trying to build a form for WSS 3.0 which has the following two characteristics:

1. Have several sub-records in each records which contains few specific fields.
2. Can export to HTML or something similar which can be viewed in every browser.

I realize (unless I'm mistaken) I can achieve 1 only by using InfoPath and RepeatingSection/RepeatingTable/etc.

As for 2, I see InfoPath is only capable for exporting to MHT/PDF/XLS, none ideal for me, since the goal is to create a something that can be published to the web.

Any hints about better way to achieve this?

Correction for 2: I meant that the InfoPath form should be editable within our intranet, but exported as a read-only-web-page for our web site. So I meant "exporting" and not "publishing".

Answer 1

Perhaps creating a custom fieldtype is a possiblity. Create a fieldtype that has some kind of collection as value.

Answer 2

Hi Moshe,

As for 2, I see InfoPath is only capable for exporting to MHT/PDF/XLS, none ideal for me, since the goal is to create a something that can be published to the web

That's not right, InfoPath forms can be published to the web. When publishing the form to the SharePoint via the InfoPath client, you can select an option saying that this form should be editable within a browser. But beware that some form features of InfoPath are not available when you do that.

Or do you have a different understanding of "can be published to the web"? For me it means, creating a new item in the library to which the InfoPath form is attached to --> Form is opened in the browser --> user fills in the form --> user klicks the save button --> info path document is saved to the library and closed.

Answer 3

Hi Moshe,

Just an idea:

If InfoPath (along with MOSS) is not an option, then perhaps you could mimic its behaviour through a custom edit form, if you want the data to be outputted into a SP list. I'm thinking about a custom edit form with dynamic html controls (for the sub-records), and you can achieve this by dynamically inserting objects into the DOM as your tree structure requires. Then, on form submit, an event handler on the list would parse the data submitted by the form and store it as you see fit (in an xml serialized in a custom field, for example).

If it's not going the be a custom edit form for a list, then the same functionality above can be stored in a site page with code-behind (beware of customizations) and use a hidden SP list as your data storage.

As for the exporting section, perhaps an application page linked in the ECB menu of that list would get the above mentioned xml and display it nicely.

Answer 4

One way to do this would be to use a database as the primary data source for your forms, so that all form data is saved there. You could then build a website that queries the database for all info.

Another alternative would be to take the infopath form data (saved as an xml file) and publish it on a web server with an XML Style Sheet to define its format. You could do this via an XML control in ASP.net.

These solutions might require more elbow grease than some other solution, but I believe either would work.