wizard-like data collection implementation help (next, next, finish)

Question

I'm beginning to build an interface for our field techs to close out work orders and we have many different required paper forms for different customers. I had hoped to build a system where i can set up a Page for each form (all in .Net 4.0/wpf and possibly using caliburn.micro if it's not a bad choice), and based on rules, display certain pages automatically. I've started out by setting up a basic framework consisting of a wpf form with 3 buttons (back, next/finish, cancel) and a Frame. In the end i hope to have an object i can pass an identifier that will go get all the information it needs, decide which pages to show, show them in order, and update our database when the user clicks finish.

Is there anything specific i should be researching/learning to make my job easier, or my finished product more robust/reliable? What would be a good approach to decide which pages to show? Mostly it would be based on something like Show this form if Customer is X but i'd like to be able to be more complex(extensible?) than that if i need. In the end, each page/form will probably also generate a PDF file of the customer's actual form, filled in. Sounds like a routine thing to have, but i've never personally implemented or used anything that did it, myself, so i'm going in blind. would the hosting window ask the page if they need to be shown? should the pages speak up themselves? should the hosting window pass the entire data object to a bool function ShouldIShowYou() and let the page sort it out? there has to be some mechanism already in place for me to "register" a page as being for a certain "something," but i'm not sure what it is. I'd like it to be fairly easily updated, but the app is deployed via clickonce and total number of users will be under 100 for the foreseeable future. just adding a new page object + logic to the collection and re-deploying shouldn't cause trouble.

a few other questions i had:

• could(should) i implement this as a transaction in .net, where i could start a transaction when the window/object is created, have each individual page in the frame do it's own data work (via a shared wcf proxy), then commit the transaction after everything works out?

• should each page just build up an object and the main window pass the object back and have the originating application do the data work? e.g. make the whole segment of the application be data-unaware. not sure this would work out very well, sounds like a maintenance nightmare.

• is this the wrong place to put this kind of question? i'm not looking for code, so it didn't feel right in overflow. this is more of a "what are the words to describe what i'm trying to do" question.

Thanks!

i'll re-read this 10 or 12 times over the course of the day and try to clarify if i can. My brain-speak don't always make gud words.

Answer 1

A lot of the design for a system like this comes down to the users really, how connected they are and what sort of connections they have. Also - how important it is to you to have the results straight away, or whether a 'sync' approach is ok...

'Field techs' sounds like the sort of people who will be working in a disconnected way?

So you'll probably want to be looking at some way of storing results and syncing them when online? That leads to a whole ream of things like SQL CE, maybe embedded RavenDB, something on the local machine (maybe even a simple CSV). When they are online - sync to a service which can collate all the responses.

In terms of the pages themselves, depending on how many there are / planned to be in the long term either just whack them all into the project, or if they can be grouped, maybe individual class libraries for each group of pages. Then either deploy the lot (if the package is a moderate size & the field techs have decent connections) or bring them down on demand, or maybe even distribute them separately and use something like MEF to load them dynamically.

You've tagged the question with MVVM so, you know about the pattern. The VM's should be directing your pages, the 'next' command will (or should!) know which page to load next. In terms of which pages to show based on which customer, to make it more 'generic' you'd probably want to store the customer information somewhere, maybe in the service - and sync that down to the field techs when they sync up / install the software.

You can do things like code string expressions in databases to dynamically generate rules (http://www.fidelitydesign.net/?p=333), and add super-complexity - however I would avoid making the code more complex - start simple, get it working and then hit the complexity if it's needed.

For PDF generation, I would google for XAML PDF Generation, or if you have the data in a database at that point, the world is your oyster, there are some great free PDF writers (iTextSharp etc) and some not-so-free - but also good (PDFKit). Depends on whether you have a tight budget, or a not so tight budget :)