On Thu, 14 Mar 2002, Peter Lynch wrote:
> The idea of different conduits not requiring different actions or even > screens may not play out as cleanly as it first might appear. Our app serves > vxml, xml and html screens. Currently we've managed with having one set of > actions for all conduits, but there are cases where even doing that can be > tricky. > > For example suppose I have a pretty html form with various check boxes and > radio buttons indicating user selections. With my vxml interface, these same > choices are not present because the html choices are just there for the > convenience of filling out the html form. > > Now in the action class, I have to account for both, which depending can get > kind of messy. > So indeed the actions care about where those values came from. Luckily there > have been only a few cases like this so far. I think that you're confusing where the processing should go. It makes more sense (at least from my point of view) to have different actions for each of these screens (ActionXML, ActionHTML, ActionVXML, ActionFlash, etc) and within those actions only account for getting the data and passing it to the real object that does the work. All of my actions follow the general template: //Get the paramaters from rundata (or wherever it is coming from) //Create an instance of the object that needs to do the real processing //Pass the parameters i.e. object.method(parameters) That way there is no logic being performed in the actions themselves, other than getting the input data to the real method that does the work, and it allows them to take input from any number of sources without bending over backwards to figure out where it is coming from. Plus you still have the conveinence of only maintaining one code base to do the actual data processing. This would also allow you to take all of the logic that you write with you to the Next Great Framework (TM), or GUI, or 3-D virtual environment, etc, should the need ever arise to drop Turbine as a front end. (Which it won't, of course ;-) ) -Kurt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
