Thank you for the answer. It has provided a lot of food for thought for my and my coworkers. -- Humberto
-----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 7:45 PM 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]>
