You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Humberto Hernadez Torres <hh...@itweb.com.mx> on 2002/01/04 00:44:44 UTC
When to use screens vs. actions
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?
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)
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 + (?)
What would correspond to session beans in the model. Actions? Screens?
Additional Java Objects?
If you do a setTemplate() within a Screen.java, Shouldn`t that be parte of
the controller?
We are kind of confused and would like to understand this better to make a
good use of Turbine.
--
Humberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: When to use screens vs. actions
Posted by Scott Eade <se...@backstagetech.com.au>.
From: "David Wynter" <da...@btclick.com>
> 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.
My pull tool is bigger than yours!!! ;-)
Seriously though, I too had/have a lot of functionality concentrated
in a single pull tool. I did actually move a bunch of the code back
into the torque classes and this simplified things quite a bit. Before
my template may have included a couple method invocations to my
pull tool, but more often this is now one method invocation on the pull
tool and another on the result. This has worked really well and I am
much happier with the size and complexity of my pull tool (I can't help
it, I have to laugh when I write this).
My application splits functionality between four groups of users and
I have recently given consideration to splitting the pull tool into two
or even four separate pull tools that support these different groups of
users. In one case this will simplify things greatly as there is a
particular group of users whose functionality is limited in in a certain
way that might be more consistently enforced using an isolated tool.
> 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.
Other ways to get the primary keys are to pass them as query data or
to retain a limited set in User.Temp. I find these methods work very
well - the only time I use an action is when a form is involved.
HTH
Scott
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: When to use screens vs. actions
Posted by David Wynter <da...@btclick.com>.
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:jvanzyl@zenplex.com]
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" <hh...@itweb.com.mx>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: When to use screens vs. actions
Posted by Jason van Zyl <jv...@zenplex.com>.
On 1/3/02 6:44 PM, "Humberto Hernadez Torres" <hh...@itweb.com.mx>
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>