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]>
