>I'm using WWWC for this project. What I was curious about was creating an XML object to maintain state.

Basically you can use wwXML::ObjectToXML() to persist an object. So you can capture user input into an object, then store that object into XML and into a session object, and pick it up in the next request. If you have very complex forms and lots of data from the user to grab this is a very easy way to maintain state between requests that directly maps to your business objects. You basically write very little code.

In Web Connection this works something like this:

* Always display content from Business objects on HTML forms using tempaltes.
in forms you'd do things like %= BusObject.Property % (angle tags ommitted)

* You can then directly capture back into the business object with
Request.GetFormVarsToObject( loBusObject )

* Once you have the bus object populated (and possible do minor fixup ont
on the captured input) you persist to XML and store it into XML

* Next hit (or 5 hits down the line for that matter) you can simply
restore the object from the XML.

It's very flexible and requires very little code. If the object structure changes you don't re-write any code. It's all loosely coupled - the only thing that needs to be updated is any property fixups - but in theory you can have your business object take care of that with a .ValidateDate() type method.



>The potential problem would be if someone was to complete the pager setup, then for whatever reason hit the back button to one of the option choice pages. Any option choices that were displayed would have already been verified, so the user wouldn't see an error till they hit the final page and submitted the options for activation. They would then receive a message that the phone number is already active.

Well, that's why state saving is a good idea. You never write anything into the database until the entire process is finalized. All state is temporary until the user gets to the end and says - yeah all is good - now do it.

>From reading the prior message about an XML object to maintain state, a lightbulb went on that I could have an object stored on the server that could be checked at each page submission to verify that all the necessary pages had been visited.

You probably don't really need that because you can store all of the data in the object (or objects) required for the transaction.

It helps to have really clean and modular business objects that cater to this architecture which is worthwhile even if you don't use XML. Basically, if objects are treated as transactional components (ie. step by step operation), then it becomes easy to have the business object deal with all the details. For example, having a ValidateData() method could deal with any data fixups required - you could even build some generic handlers that can deal with proper data conversions and type fixups that sometimes occur with XML.


XML has so many useful applications it's hard not to get excited about this technology. While I agree with arguments that XML is not the best solution in all situations, one thing that you find is that you can mold it into most situations. And for consistency you can hardly beat it because you'll end up using hte same tools in all sorts of places, which makes the process of development that much easier!