Hi, comments below,
> 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. You should always need different Screens if the conduits are vastly different in nature eg. web app vs wap app vs kde/win app. Obviously different screens means different screen flows so this also needs to be different (there are ways around this as well, but it really depends on what you want to achieve). However, it is entirely possible to code your actions eg. validation of information, into reusable modules of code. In Turbine, screens are your Velocity Templates (just as one example). Your screen flow can either be controlled by the corresponding Screen Class, or the ActionEvent Class. What you do here can make a big difference in the reusability of your code. > 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. How the data is presented to your action is the key here. Regardless of how your interface looks, the data requirements for a particular field should not be different if the application is the same i.e if a field requires a 'y' or 'n' value, it will always require a 'y' or 'n' value, regardless of how the gui decides to collect this information (eg. radio, textbox). Huy > For screens, early on, we anticipated correctly I think that even though the > application works the same as a whole, we would need different screen > classes for vxml, html, and of course xml. > > -Peter
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
