You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Akshay Kapur <ak...@cisco.com> on 2003/01/09 22:10:01 UTC
Design question
I am trying to figure out the design of the presentation layer in my
application. Please let me know your suggestions, and standard coding
techniques based on the MVC model -
Here's a typical case I need to design -
1. A form is displayed for the first time the user logs on.
2. After form submit, the data is either saved to the database or in case
of data-error, the form is re-displayed with the error message.
a. I would like to know if the following code represents a standard way of
implementing the above case.
b. As you can see, I am not using any screen java class corresponding to
form.java(the ones under the screen directory). So when is a screen class
used? Basically I am trying to figure out the line between an action and a
screen class.
public class FormAction extends VelocityAction
{
public void doView(Rundata data, Context context)
{
//get the request params
.
//on the basis of request params, populate the context for the template
.
setTemplate( data, "form.vm" )
.
//set data in HttpSession
}
public void doSubmit(Rundata data, Context context)
{
//get the request params
.
//get data from HttpSession
.
biz = new Biz( request );
biz.validate();
if ( formDataError )
{
context.put( "Data invalid. Please reenter data" );
this.doView(Rundata data, Context context);
}
biz.saveToDatabase();
}
}
Re: Design question
Posted by Rodney Schneider <ro...@actf.com.au>.
On Fri, 10 Jan 2003 10:09, you wrote:
> It took me a while and the help from Quinton McCombs, Rodney
> Schneider and Scott Eade to come to appreciate what Turbine is doing,
> though my understanding is still not complete yet.
>
> According to my understanding, Turbine follows a structured sequence
> in displaying a page. It always look for a java class file to execute
> prior to the display/action, if it fails that, it will execute the
> Default.class file as pre-defined in the TR.props file.
The best way to understand Turbine's execution path is to read this
document, especially the "System Flow" section:
http://jakarta.apache.org/turbine/turbine-22/fsd.html
Then read all of the appropriate Howtos:
http://jakarta.apache.org/turbine/turbine-22/howto/index.html
It might surprise you how many helpful tips you might find by scouring
the Turbine site and reading the docs carefully.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Design question
Posted by Rodney Schneider <ro...@actf.com.au>.
On Fri, 10 Jan 2003 11:05, you wrote:
> On Fri, 10 Jan 2003 10:09, you wrote:
> > It took me a while and the help from Quinton McCombs, Rodney
> > Schneider and Scott Eade to come to appreciate what Turbine is
> > doing, though my understanding is still not complete yet.
> >
> > According to my understanding, Turbine follows a structured
> > sequence in displaying a page. It always look for a java class file
> > to execute prior to the display/action, if it fails that, it will
> > execute the Default.class file as pre-defined in the TR.props file.
>
> The best way to understand Turbine's execution path is to read this
> document, especially the "System Flow" section:
> http://jakarta.apache.org/turbine/turbine-22/fsd.html
Also, I recommend stepping through the Turbine code in a debugger...
this will aid your understanding of the Turbine internals immensely.
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Design question
Posted by Rodney Schneider <ro...@actf.com.au>.
On Sat, 11 Jan 2003 05:01, you wrote:
> Thanks Rodney. I have started looking into the mail archives for Pull
> tool talk. Is there any sample code I can lay my hands on?
Apart from what you might find in the archives, there are several pull
tools that come bundled with the TDK for you to look at. Have a look
in the Pull Service section of TurbineResources.properties.
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Design question
Posted by Akshay Kapur <ak...@cisco.com>.
Thanks Rodney. I have started looking into the mail archives for Pull tool
talk. Is there any sample code I can lay my hands on?
Thanks
Akshay
At 03:25 PM 1/10/2003 +1100, you wrote:
>On Fri, 10 Jan 2003 14:18, you wrote:
> > Thanks to all the responses that came in today.
> >
> > I have already read the Turbine docs and do understand the details of
> > the system flow. My question was more on the design approach. Anyway,
> > what I do conclude now is that let Action classes come into play only
> > when there has been a form submit. and screen class handle the view
> > code.
>
>Yes. Typical Action classes process the form data and perform inserts
>and updates on the database. Your Screen classes should never need to
>modify the database. Typical Screen classes perform security checks
>and set up the context for the view templates. This is known as the
>"push" model.
>
>Another approach is the "pull model" using the Turbine Pull Service:
>http://jakarta.apache.org/turbine/turbine-22/pullmodel.html
>http://jakarta.apache.org/turbine/turbine-22/services/pull-service.html
>
>In the pull model, Screen classes are generally only used to perform
>security checks, _not_ to set up the context. A typical pull tool is
>used like so:
>
>
>--BACK END--
>pullTool <-- service (abstracts access to database) <-- database
>------------
>
>--TEMPLATE--
>#set ($modelObjectOne = $pullTool.modelObjectOne)
>#set ($modelObjectTwo = $pullTool.modelObjectTwo)
>...
>#foreach ($item in $modelObjectOne)
>...
>#end
>
>This is your $modelObjectTwo
>------------
>
>
>In both push and pull, it is generally best to put much of your logic
>within a Turbine Service with a well defined interface. This will
>allow you to call the methods of your service from any action, screen
>or pull tool within your application.
>
>Hope that helps,
>
>-- Rodney
>
>--
>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: Design question
Posted by Rodney Schneider <ro...@actf.com.au>.
On Fri, 10 Jan 2003 14:18, you wrote:
> Thanks to all the responses that came in today.
>
> I have already read the Turbine docs and do understand the details of
> the system flow. My question was more on the design approach. Anyway,
> what I do conclude now is that let Action classes come into play only
> when there has been a form submit. and screen class handle the view
> code.
Yes. Typical Action classes process the form data and perform inserts
and updates on the database. Your Screen classes should never need to
modify the database. Typical Screen classes perform security checks
and set up the context for the view templates. This is known as the
"push" model.
Another approach is the "pull model" using the Turbine Pull Service:
http://jakarta.apache.org/turbine/turbine-22/pullmodel.html
http://jakarta.apache.org/turbine/turbine-22/services/pull-service.html
In the pull model, Screen classes are generally only used to perform
security checks, _not_ to set up the context. A typical pull tool is
used like so:
--BACK END--
pullTool <-- service (abstracts access to database) <-- database
------------
--TEMPLATE--
#set ($modelObjectOne = $pullTool.modelObjectOne)
#set ($modelObjectTwo = $pullTool.modelObjectTwo)
...
#foreach ($item in $modelObjectOne)
...
#end
This is your $modelObjectTwo
------------
In both push and pull, it is generally best to put much of your logic
within a Turbine Service with a well defined interface. This will
allow you to call the methods of your service from any action, screen
or pull tool within your application.
Hope that helps,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Design question
Posted by Akshay Kapur <ak...@cisco.com>.
Thanks to all the responses that came in today.
I have already read the Turbine docs and do understand the details of the
system flow. My question was more on the design approach. Anyway, what I do
conclude now is that let Action classes come into play only when there has
been a form submit. and screen class handle the view code. (The only reason
I was thinking of building the view in an action method was due to the fact
that I saw some code in Jetspeed action classes that had some view methods
like buildNormalContext())
Regards
Akshay
At 11:24 AM 1/10/2003 +1100, you wrote:
>On Fri, 10 Jan 2003 11:05, you wrote:
> > On Fri, 10 Jan 2003 10:09, you wrote:
> > > It took me a while and the help from Quinton McCombs, Rodney
> > > Schneider and Scott Eade to come to appreciate what Turbine is
> > > doing, though my understanding is still not complete yet.
> > >
> > > According to my understanding, Turbine follows a structured
> > > sequence in displaying a page. It always look for a java class file
> > > to execute prior to the display/action, if it fails that, it will
> > > execute the Default.class file as pre-defined in the TR.props file.
> >
> > The best way to understand Turbine's execution path is to read this
> > document, especially the "System Flow" section:
> > http://jakarta.apache.org/turbine/turbine-22/fsd.html
>
>Also, I recommend stepping through the Turbine code in a debugger...
>this will aid your understanding of the Turbine internals immensely.
>
>-- Rodney
>
>--
>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: Design question
Posted by "m. lin" <mi...@eigentechnology.com>.
It took me a while and the help from Quinton McCombs, Rodney Schneider and
Scott Eade to come to appreciate what Turbine is doing, though my
understanding is still not complete yet.
According to my understanding, Turbine follows a structured sequence in
displaying a page. It always look for a java class file to execute prior
to the display/action, if it fails that, it will execute the Default.class
file as pre-defined in the TR.props file.
To use your example, if you have a html page that is going to post a form,
then you need to write this line in your html page:
<form method="post" action="$link.setAction("FormAction")">
</form>
or
<form method="post" action="$link.setPage("A.vm").setAction("FormAction")">
</form>
(see setPage("A.vm") below).
upon submitting this form, Turbine will look for a FormAction.class to
execute. I stumbled on this for a while, because of the security
restriction imposed upon the FormAction.class. There are three ways this
security can be done:
/ 1. No security your FormAction extends VelocityAction
/
/
submit Form--- 2. Standard security your FormAction extends SecureAction
\
\
\ 3. overriding security your FormAction extends SecureAction
but overrides it.
The SecureAction.java defines how security is implemented, if you want to
do some global redirection / or assign things to roles/group/permission,
you can do it here. The trick is in the isAuthorized() method which is
automatically executed (in the SecureAction class if it is extension to
the your class) everytime the class is invoked - this is not clear in any
of the documentation given, so a bit confusing for beginners.
If you are only interested in applying some special security stuff to a
specific FormAction, you then write your isAuthorized() method explicitly
in your FormAction.java, the one in SecureAction() is then overriden.
Alternatively, if you are not interested in having any security at all,
just extend VelocityAction, then no security check is performed.
A.vm page:
After performing the Form action and submitting the form itself, we need
to return to a page somewhere, this is where is
<form method="post" action="$link.setPage("A.vm").setAction("FormAction")">
</form>
comes into picture. It this setPage("A.vm") is not given in the above line
in your html file, you then need to define it in your FormAction.java
file:
data.setScreenTemplate("Somepage.vm");
if neither is given, then Turbine will throw you back to the Login.vm -
which really confuses me a lot, because each screen is subject to its own
set of security checks!!
The security check for each screen is set out just like the forms,
however, it is called SecureScreen.java under screen dir.
/ 1. No security your SomePage extends VelocityScreen
/
/
submit HTML--- 2. Standard security your SoemPage extends
VelocitySecureAction
\
\
\ 3. overriding security your SomePage extends
VelocitySecureAction
but overrides it.
So, if you want your Secure Form to work smoothly, you need to go through
the whole works with the Screen as well.
hope that helps, I am sorry it is a bit long, I am not good at being
concise, appology to others.
michael
> I am trying to figure out the design of the presentation layer in my
> application. Please let me know your suggestions, and standard coding
> techniques based on the MVC model -
>
> Here's a typical case I need to design -
> 1. A form is displayed for the first time the user logs on.
> 2. After form submit, the data is either saved to the database or in
> case of data-error, the form is re-displayed with the error message.
>
> a. I would like to know if the following code represents a standard way
> of implementing the above case.
> b. As you can see, I am not using any screen java class corresponding to
> form.java(the ones under the screen directory). So when is a screen
> class used? Basically I am trying to figure out the line between an
> action and a screen class.
>
> public class FormAction extends VelocityAction
> {
> public void doView(Rundata data, Context context)
> {
> //get the request params
> .
> //on the basis of request params, populate the context for the
> template .
> setTemplate( data, "form.vm" )
> .
> //set data in HttpSession
> }
>
> public void doSubmit(Rundata data, Context context)
> {
> //get the request params
> .
> //get data from HttpSession
> .
> biz = new Biz( request );
> biz.validate();
> if ( formDataError )
> {
> context.put( "Data invalid. Please reenter data" );
> this.doView(Rundata data, Context context);
> }
>
> biz.saveToDatabase();
> }
> }
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Design question
Posted by Eric Emminger <er...@ericemminger.com>.
Akshay
> application. Please let me know your suggestions, and standard coding
> techniques based on the MVC model -
I'll give you some suggestions, but I don't know if they're "standard."
> a. I would like to know if the following code represents a standard way of
> implementing the above case.
It's close.
> b. As you can see, I am not using any screen java class corresponding to
> form.java(the ones under the screen directory). So when is a screen class
> used? Basically I am trying to figure out the line between an action and a
> screen class.
The screen class is used to populate the context, etc. See
http://jakarta.apache.org/turbine/turbine-2/howto/velocity-site-howto.html
> public class FormAction extends VelocityAction
> {
> public void doView(Rundata data, Context context)
Instead of your doView() function, put this logic in doBuildTemplate()
of a Screen class. If your screen is Form.vm then make a Form.java
screen. Read everything on the Turbine site.
> public void doSubmit(Rundata data, Context context)
> {
> //get the request params
> .
> //get data from HttpSession
> .
> biz = new Biz( request );
> biz.validate();
> if ( formDataError )
> {
> context.put( "Data invalid. Please reenter data" );
> this.doView(Rundata data, Context context);
> }
>
> biz.saveToDatabase();
> }
> }
That's pretty much what I do and it works well.
Does that help?
Eric
--
Eric Emminger
eric@ericemminger.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>