below.... ----- Original Message ----- From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Turbine Users List" <[EMAIL PROTECTED]> Sent: Thursday, March 14, 2002 6:47 AM Subject: Re: Action Chaining > On Wed, 2002-03-13 at 22:41, Kurt Schrader wrote: <snip/> > That will work. It's probably just better to to not have much logic in > > your actions though. I just get the parameters I need and pass them to > > the objects that need them to run. That way you can use the same logic in > > any number of actions. > > +1 > > If you are going to use actions and place logic in there that > manipulates your object model then make them execution environment > agnostic. By that I mean remove the dependency on the servlet in your > actions. > > This will be part of the roadmap for 3.0. Where the core of your turbine > app is contained in an application model and there will be different > conduits to bring information from the view to the model. As Kurt > pointed out all you really need is a mechanism to get the values need by > your 'action' to perform it's job. The 'action' shouldn't care where > those values come from. Currently in Turbine it is usually from a web > page, but we certainly don't have to limit ourselves to this.
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. 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]>
