Using Intake may be helpful. I haven't used it much, but my messing with it seems to indicate that the processing of the form is a lot cleaner. Maybe your actions could become simpler?
----------------------------------------------------------------- Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com ----------------------------------------------------------------- > -----Original Message----- > From: David Wynter [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 4:15 AM > To: Turbine Users List > Subject: RE: When to use screens vs. actions > > > MTCW > > Having watched the mailing list closely it was evident that > screen classes > were going the way of the Dodo. So in preparation for T3 we > used Actions and > Pull tools. We put all pull tools in one class after some > discussion about > whether the OR classes should carry out this function. It was > decided that > there were quite a lot of joins being made that was not > appropriate for the > OR classes, they provide a support role. The downside is that > this Pull tool > class has become fairly large and unwieldy. > > To add to what has been said below, our Action classes are > required to build > quite a bit of the context due to the omission of the Screen > class. The Pull > tool needs to have the primary keys of all the entities it > needs to flesh > out for the screen so these have to come from the Action class. So our > Action classes are split into 2 sections, process the form and do the > database operation/s, then in the 2nd section dependent on > the result, build > the appropriate context, including error messages if required. > > The explanation below by Jason should be edited and put on > the Turbine site, > there is really little guidance on good practice for the > future generations > of Turbine in the current documentation. While Jason says > others may not > agree to his explanation of the MVC and how the current > design fits it, it > is better than nothing. > > David > > > > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: 04 January 2002 01:45 > To: Turbine Users List > Subject: Re: When to use screens vs. actions > > > On 1/3/02 6:44 PM, "Humberto Hernadez Torres" > <[EMAIL PROTECTED]> > wrote: > > > We have been using Turbine for some time but we have this > philosophical > > question: > > > > When a should a java functionality should be implemented > as an action or > in > > the .java file of a screen? > > Screens in 2.1 are what I like to call a context builder, you > use a screen > to add items to the context so they are available for use in > a template. I > generally think of actions as processes responding to choices > made in the > view. > > > Some cases are clearly actions like adding a record to the database. > > Other cases are clearly screens like displaying an items > information. > > Other cases are not as clear like searching for records in > the database or > > doing a validation on a form. > > > > The rule of thumb we have been using is: If it modifies the > database is an > > action. Screens should never modify the database. (or for > that matter the > > state of the application) > > That's a pretty good rule of thumb, I think. > > > We looked in the information on the turbine site and didn`t find a > reference > > on the subject. > > > > A related question would be what is the matching between > MVC and Turbine: > > Controller = TurbineServlet + Actions. > > View = Screens + Layouts + Navigations. > > Model = Entity Beans + Session Beans = Peers Object Model + (?) > > The TurbineServlet is definitely the controller, as the > controller mediates > between the view and the model. > > In Turbine I consider the templates the view, so under the > classic model in > Turbine the screen, layout, and navigation templates comprise > the view. The > nomenclature is somewhat confusing because there are screen > templates and > screen classes. Screen templates are the .vm files and screen > classes are > modules in Turbine and are responsible for making various > portions of your > application model accessible in the templates. So if we assume the > definition above in the first paragraph than the screen classes can be > thought of as part of the controller as it is a bridge between your > application model and your view. This is how I think of it > and may or may > not mesh with the way others think of it. > > Actions are also a confusing point because an action may > simply be passed > information gleaned from input taken from the view and do > something with it. > So in this case the action is purely manipulating the model. > But actions can > change what the user sees next based on some logic so in > effect the action > is using information from the view in conjunction with some > information from > your application model and changing what is seen. So in this > case I would > say it's acting as a controller. > > I think the whole setup is hard to define because the MVC > model was lifted > from GUI application programming and I don't think it quite > fits exactly > with webapps. This is only my take on the current situation. > > In Turbine 3.x we are trying to move away from screen classes > and replacing > them with pull tools. Pull tools are used heavily in Scarab > and they are > being used quite a bit in Tambora now as well. A pull tool > basically allows > you to put a piece of your application model into the view > and have that > piece of the model be accessible in all your templates. The > idea is that you > are freed from having to write a screen class for each of your screen > templates. > > > > What would correspond to session beans in the model. > Actions? Screens? > > Additional Java Objects? > > I don't use any EJB so I'm just not familiar enough with the > technology to > comment. > > > If you do a setTemplate() within a Screen.java, Shouldn`t > that be parte of > > the controller? > > Yes, I would say that the screen in that instance is acting like a > controller. I think we as the Turbine developers would be > hard pressed to > give you hard and fast definitions and rules for strict usage. > > > > We are kind of confused and would like to understand this > better to make a > > good use of Turbine. > > Looking at some pull tools might be your next logical step. > As Turbine 3.x > matures a little I hope we get some more pointed questions > like you have > presented so it forces us to define things a little better. Turbine is > flexible because of some of this lack of definition, but we > also realize > this makes things sometimes complication. I feel that most of this > complication can be removed eventually but at the moment the above > explanation is the best I can do. Others may have a more > salient commentary. > > > -- > > Humberto > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > > jvz. > > Jason van Zyl > > http://tambora.zenplex.org > http://jakarta.apache.org/turbine > http://jakarta.apache.org/velocity > http://jakarta.apache.org/alexandria > http://jakarta.apache.org/commons > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
