Off-Topic: JMS Design Question...

[Ajay Chitre]

Hello,
 
This is kind of off-topic, so I apologize in advance.  We do have some
J2EE gurus on this mailing list so I decided to ask it here.  (Is there
any other *active* mailing list where I can post JMS related questions?)
 
Anyway, I need some help to develop a JMS based solution. Here's what we
are trying to accomplish;
 
We need to send XML messages (as well as other types of messages) back &
forth between two Application Servers. In other words, a Web Application
created by us will send a message to the application server of our
client and vice versa. 
 
This is what I was thinking of doing;
 
1) When it's time to send a message on our side, we will write it to a
Topic in our App Server.
2) A MDB on our side will retrieve the message and send it to the Topic
of our client.
 
The same logic will apply for incoming messages;
1) Client will write a message to our Topic.
2) A MDB on our side will then pick up this message and process it.
 
If this sounds okay, then I am wondering how I can handle Exception
conditions.  For example;
 
1)  If Client's App Server is down, then our MDB should keep resending
till the message is sent successfully.  How can I do this in JMS?
2)  If our JMS Server is down (shouldn't happen, but let's say it does)
what should the Web App do?  Would "Durable Subscriptions" help in this
case?
 
I would greatly appreciate any input in this matter. Thanks (a lot) for
your time.
 
- Ajay

Design question Permission check in struts action

[Dirk Storck]

I have the following system:

I have a LoginDataForm called loginDataBean in my seesion wich contains
username, password and roles the user have. Than I have some actions
accessing EJB through helper classes. For example I have a action
/order/detail/show. If that action is called by a normal user he can only
browse order details from orders wich belong to him (that action retrieves
an OrderVO wich contains the userId/username). If it is called for example
from an administrator he can browse details from all orders. 
That is not the only action wich behave like that. I have a
/user/show/personalData as well with shows the data from a certain user. If
the requested user is not the same as the user logged in and he is an admin
he will see the details else not.

CAN anyone give me a solution how I can solve that problem global without
having to check that in every action one by one ?

Many thanks!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Design question Struts -> EJB.

[Kevin . Bedell]

Bryan -

Looking at Struts as a Model, View, Controller architecture, EJB access is
a strategy that is generally used IN MODEL COMPONENTS.

 - The View components are primarily the JSP's that are used for
presentation.

 - The Controller components are the Action classes you write. These must
extend  org.apache.struts.action.Action in order for Struts to work.

These two parts of Struts are the basic framework that control the
request/response flow and build the html pages.

 - Model components provide access to back-end data stores or services. The
provide a programming "Model" that make it easy for code in the Action
classes to interact with the back-end data and services. This is where
EJB's generally are useful.

The Event model in Petstore is similar to how Action classes are used in
Struts:

  - In petstore, incoming requests were translated into Events that were
then used to execute the business logic of the request
  - In Struts, Action classes coordinate the execution of the business
logic.

The parallel isn't perfect, but it's reasonable . Of course, the real question to
ask is if you really need EJB's anymore once you're using Struts. You may,
but you may not.

Here are some places it may be useful to use EJB's in Struts - note all
these are Model component-based. (Others on the list may have other
thoughts to contribute here...):

- As in the Blueprints, there may be a session-ejb facade that provides a
front-end into a whole series of ejb's in the back-end. This session facade
would be accessed from the Action class. The Session Facade should return
Value Objects similar to petstore - these would be passed to the Views (jsp
pages) for presentation to the end-users.

- Entity beans may be used in a couple ways:
 - In the Action (Controller) class you may directly access an Entity
bean that is itself acting as a model component.
 - From the Action class, you may access a DAO (or some similar
pattern) that in turn access an entity bean
 - In either of these two cases Value Objects (sometimes referred to as
Data Transfer Objects or- DTOs) should be returned.

- From the Action class you may access a web service that is a wrapper for
a stateless bean on some container somewhere.

The common theme is this:

 - The View and Controller components in Struts manage interaction with and
presentation to the User.
 - Model components encapsulate interaction with a back-end service or
data-store. This is where EJB's are most useful.

Best of luck,

Kevin











bryan hansen <[EMAIL PROTECTED]> on 06/26/2002 06:54:33 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   [EMAIL PROTECTED]
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Design question Struts -> EJB.


I was really looking forward to read the chapter in
the book on review at theserverside.com on Struts and
EJBs. We are currently implementing a system and are
going to use struts for the web framework and ejbs for
the model. The java blueprints return an Event from
the would be action class for comparison in struts.
The struts class returns an ActionForward instead of
an Event. I think it is really elegant how they are
handling this because they can just pass an Event to
an EJBController and then get an EventResponse back.

Is there an easy way that just isn't presenting itself
where I am looking? How are other people integrating
EJBs without just opening up the entire model?

Thanks,

Bryan

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

Design question Struts -> EJB.

[bryan hansen]

I was really looking forward to read the chapter in
the book on review at theserverside.com on Struts and
EJBs. We are currently implementing a system and are
going to use struts for the web framework and ejbs for
the model. The java blueprints return an Event from
the would be action class for comparison in struts.
The struts class returns an ActionForward instead of
an Event. I think it is really elegant how they are
handling this because they can just pass an Event to
an EJBController and then get an EventResponse back. 

Is there an easy way that just isn't presenting itself
where I am looking? How are other people integrating
EJBs without just opening up the entire model?

Thanks,

Bryan

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Subclass Actions vs Request processor? - Design Question

[Jeff_Mychasiw]

I would like some clarification, Here is what I think I understand
With pre 1.1, if you wanted to perform a task for every action/page your choices
were to override the Action servlet or subclass the Action
and define an abstract myPerform() method.  The parent class would perform
common functionality in it's perform method then call the myPerform().

I also understand that it is a good idea to create a super action(s) regardless
of whether you think you will need it or not.

I am in the process of design of our first Struts app and I am at that point.

So:
1 - I think in the future,  if I want to perform common functionality for each
request, then I should plan to use the request processor.

2 - I should still create an Application specific super Action Class to hold
common helper methods but I do not need to force an abstract myPerform()

Am I off base?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Re[2]: Database access design question

[wbchmura]

Okay, here is why I was thinking that...

If I have business logic that would produce the results as a hashmap, 
but I need an arraylist to populate a control in the JSP, is the action 
now preparing data for the presentation as opposed to preparing data?  
for example, in a perfect world I should be able to take my business 
logic and use it as a desktop app if I slap a GUI on the front of it?  
Basically I would need to replace the ACTION with something else that 
would populate the data into the controls.  Hmmm, or would that be the 
JSP...

I have no idea what I am talking about...



-Original Message-
From: craigmcc [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 3:05 PM
To: struts-user
Cc: maillist
Subject: RE: Re[2]: Database access design question




On Mon, 10 Jun 2002 [EMAIL PROTECTED] wrote:

> Date: Mon, 10 Jun 2002 13:35:33 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: RE: Re[2]: Database access design question
>
>
> ANY information on this would be a great help.
>
> I am familar with the concept of patterns and have been trying to get
> used to them and how to use them...
>
> If you describe what you came up with that would be cool too!
>
> If anyone has a good illustration of the model layers that work best I
> could use that also.  I've been thinking (up till recently) that the
> ActionClass is part of the controller, but now I am thinking of it
> almost as half controller, half view.  I am tryting to segment it out 
to
> mostly setting up the data to be sent to the view, and handling input 
so
> the controller acts correctly.
>
> My head hurts sometimes, but the voices tell me it will be okay...
>

Actions are definitely in the controller tier, although in small apps
people tend to embed business logic directly in them (which makes them
somewhat part of the model tier as well).

The only time Actions are part of the presentation tier is when you are
generating the output directly from the Action (such as rendering some 
XML
content or a dynamically generated graph) rather than forwarding to a
presentation tier resource for the final output.

ActionForms, by the way, *are* part of the presentation tier -- their 
only
purpose in life is to represent the server side state of client user
interface components.

Craig


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

RE: Re[2]: Database access design question

[Craig R. McClanahan]

On Mon, 10 Jun 2002 [EMAIL PROTECTED] wrote:

> Date: Mon, 10 Jun 2002 13:35:33 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: RE: Re[2]: Database access design question
>
>
> ANY information on this would be a great help.
>
> I am familar with the concept of patterns and have been trying to get
> used to them and how to use them...
>
> If you describe what you came up with that would be cool too!
>
> If anyone has a good illustration of the model layers that work best I
> could use that also.  I've been thinking (up till recently) that the
> ActionClass is part of the controller, but now I am thinking of it
> almost as half controller, half view.  I am tryting to segment it out to
> mostly setting up the data to be sent to the view, and handling input so
> the controller acts correctly.
>
> My head hurts sometimes, but the voices tell me it will be okay...
>

Actions are definitely in the controller tier, although in small apps
people tend to embed business logic directly in them (which makes them
somewhat part of the model tier as well).

The only time Actions are part of the presentation tier is when you are
generating the output directly from the Action (such as rendering some XML
content or a dynamically generated graph) rather than forwarding to a
presentation tier resource for the final output.

ActionForms, by the way, *are* part of the presentation tier -- their only
purpose in life is to represent the server side state of client user
interface components.

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Database access design question

[wbchmura]

I have that now I think...  I get the connection and pass that to the 
program that does not have any ties to the servlets...

the olsource object does not have any knowledge of the fact its a web 
app.  I could drop the same code into a java gui and as long as I passed 
the connection it should run

(Of course I dont know what I am doing either)

Bill


public HashMap getGroupList (org.apache.struts.action.ActionServlet 
servlet, int companyId) {
java.util.HashMap list = new java.util.HashMap();
javax.sql.DataSource dataSource = null;

try {
dataSource = 
(DataSource)servlet.getServletContext().getAttribute("Oracle");
list = olsource.getGroupList(dataSource, companyId); 
  

} catch (Exception e) {
System.out.println ("Connection.process" + e);
e.printStackTrace();
}
return (list);
}




-Original Message-
From: jakarta.rainer [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 11:47 AM
To: struts-user
Subject: Re: Database access design question


Sorry but I am in another galaxy as you guys are. My problems are not 
that
complex yet and my knowledge isn't either.
I would only like to have a simple sample how I can access the Database
defined in the struts-config.xml without having to use any servlet 
depending
methodes/classes  like pageContext, sessions or what so ever. There must 
be
a way!

thanks 1000 times for a hint!

Rainer

- Original Message -
From: "Jerry Jalenak" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, June 10, 2002 3:17 PM
Subject: RE: Database access design question


> I'm needing to move my data access from my Actions to a 'pure' 
business
> bean.  Does anyone have a good example (or link) on how to create and 
use
> DAO?
>
> Thanks.
>
> Jerry
>
> -Original Message-
> From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 3:43 AM
> To: Struts Users Mailing List
> Subject: RE: Database access design question
>
>
> 1. Do not use the session bean to access the datasource... create a 
data
> access object which locates the datasource.
> 2. Lookup the datasource using a jndi name not a servlet. Register 
your
> datasource with the jndi server. (Does the servlet api implement such 
a
> method ??)
> 3. If using a connection pool (which you should really), get the
connection
> object out of the pool and use it to access the database.
>
> HTH
> Vikram
>
>
> -Original Message-
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 2:04 PM
> To: Struts Users Mailing List
> Subject: Re: Database access design question
>
>
> I want to accesss the database from a business logic bean that should 
not
> emplement *.servelet.* classes.
> But how can I then initialize the DataSource?
> like: dataSource = servlet.findDataSource(null);
>
> ??
>
> Thanks Rainer
>
>
> > What exactly is your question?
> > The samples given with Struts do not necessarily following the best
> practices, they are more like proof of concepts than anything else.
> >
> > Rgs
> > Vikram
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 1:45 PM
> > To: Struts Users Mailing List
> > Subject: Database access design question
> >
> >
> > Hi,
> >
> > I am using the Struts Database pooling.
> > My database connection is realised after the sample in the Struts 
User's
> > Guide.
> > 
http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > But I think the sample is very contradicting.
> > In chapter 2.5 Business Logic Beans is said:
> > "For maximum code re-use, business logic beans should be designed 
and
> > implemented so that they do not know they are being executed in a 
web
> > application environment. If you find yourself having to import a
> > javax.servlet.* class in your bean, you are tying this business 
logic to
> the
> > web application environment. "
> >
> > but chapter 2.6 is Accessing the Database in the sample via a
> ActionServlet:
> > public ActionForward
> >perform(ActionMapping mapping,
> >ActionForm form,
> >HttpServletRequest request,
> >HttpServletResponse response)
> > {
> >  javax.sql.DataSource dataSource;
> >  java.sql.Connection myConnection;
> >
> >  try {
> >dataSource = servlet.findDataSource(null);
> >myConnection = dataSource.getConnection();
&

RE: Re[2]: Database access design question

[wbchmura]

ANY information on this would be a great help.  

I am familar with the concept of patterns and have been trying to get 
used to them and how to use them...  

If you describe what you came up with that would be cool too!

If anyone has a good illustration of the model layers that work best I 
could use that also.  I've been thinking (up till recently) that the 
ActionClass is part of the controller, but now I am thinking of it 
almost as half controller, half view.  I am tryting to segment it out to 
mostly setting up the data to be sent to the view, and handling input so 
the controller acts correctly.

My head hurts sometimes, but the voices tell me it will be okay...







-Original Message-
From: maillist [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 10:29 AM
To: struts-user
Subject: Re[2]: Database access design question


On Monday, June 10, 2002, 10:13:34 AM, wbchmura wrote:

wEBc> I took a quick look at the yahoo site - and will pursue that 
further, 
wEBc> but can you recommend any write-ups anywhere on this?

  I just went through the same struggles you are going through.
  Robert wrote up a great post that really helped clarify things
  for me. I'm trying the find the post now and I'll send it to
  you. (I have it saved at home and if I can't find it I'll send
  it to you later).

  Also be sure to check out Chuck's chapter 6 at this link:
  http://www.theserverside.com/resources/strutsreview.jsp

  Vic's webPIM application handles the architecture in a different
  way and you could find out more by downloading the sample app:
  http://www.basebeans.com/downloads.jsp

  I'll also send you what I came up with if you are interested
  (which for the most part follows the design principals Robert
  and Chuck helped me understand).

-- 

Rick
mailto:[EMAIL PROTECTED]

"Instead of studying for finals, what about just going to the Bahamas
and catching some rays? Maybe you'll flunk, but you might have flunked
anyway; that's my point." 
  -Jack Handey


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

Re: Database access design question

[Ted Husted]

You can't access the generic datasource pool defined by the Struts
config from the business tier. The closest you can come is to pass up
the connection. The Struts generic datasource is really * not * the best
way to go for most applications. I do not recommend using it for
production applications. 

Many DBMS packages and containers provide their own connection pools,
including Tomcat 4 I believe. 

My best general recommendation is to grab Poolman 1.4 from 

http://sourceforge.net/project/showfiles.php?group_id=4899

and see:

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg25554.html


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


rainer juenger wrote:
> 
> Sorry but I am in another galaxy as you guys are. My problems are not that
> complex yet and my knowledge isn't either.
> I would only like to have a simple sample how I can access the Database
> defined in the struts-config.xml without having to use any servlet depending
> methodes/classes  like pageContext, sessions or what so ever. There must be
> a way!
> 
> thanks 1000 times for a hint!
> 
> Rainer
> 
> - Original Message -
> From: "Jerry Jalenak" <[EMAIL PROTECTED]>
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Sent: Monday, June 10, 2002 3:17 PM
> Subject: RE: Database access design question
> 
> > I'm needing to move my data access from my Actions to a 'pure' business
> > bean.  Does anyone have a good example (or link) on how to create and use
> > DAO?
> >
> > Thanks.
> >
> > Jerry
> >
> > -Original Message-
> > From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 3:43 AM
> > To: Struts Users Mailing List
> > Subject: RE: Database access design question
> >
> >
> > 1. Do not use the session bean to access the datasource... create a data
> > access object which locates the datasource.
> > 2. Lookup the datasource using a jndi name not a servlet. Register your
> > datasource with the jndi server. (Does the servlet api implement such a
> > method ??)
> > 3. If using a connection pool (which you should really), get the
> connection
> > object out of the pool and use it to access the database.
> >
> > HTH
> > Vikram
> >
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 2:04 PM
> > To: Struts Users Mailing List
> > Subject: Re: Database access design question
> >
> >
> > I want to accesss the database from a business logic bean that should not
> > emplement *.servelet.* classes.
> > But how can I then initialize the DataSource?
> > like: dataSource = servlet.findDataSource(null);
> >
> > ??
> >
> > Thanks Rainer
> >
> >
> > > What exactly is your question?
> > > The samples given with Struts do not necessarily following the best
> > practices, they are more like proof of concepts than anything else.
> > >
> > > Rgs
> > > Vikram
> > >
> > > -Original Message-
> > > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 10, 2002 1:45 PM
> > > To: Struts Users Mailing List
> > > Subject: Database access design question
> > >
> > >
> > > Hi,
> > >
> > > I am using the Struts Database pooling.
> > > My database connection is realised after the sample in the Struts User's
> > > Guide.
> > > http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > > But I think the sample is very contradicting.
> > > In chapter 2.5 Business Logic Beans is said:
> > > "For maximum code re-use, business logic beans should be designed and
> > > implemented so that they do not know they are being executed in a web
> > > application environment. If you find yourself having to import a
> > > javax.servlet.* class in your bean, you are tying this business logic to
> > the
> > > web application environment. "
> > >
> > > but chapter 2.6 is Accessing the Database in the sample via a
> > ActionServlet:
> > > public ActionForward
> > >perform(ActionMapping mapping,
> > >ActionForm form,
> > >HttpServletRequest request,
> > >HttpServletResponse response)
> > > {
> > >  javax.sql.DataSource dataSource;
> > >  java.sql.Connection myConnection;
> > >
> > >  try {
> > >dataSource = servlet.findDataSource(null);
> > >myConnection = dataSource.getConnection();
> > >
> > > Now I am pretty confused since I want to implement the Database Access
> in
> > a
> > > buiseness logic bean.
> > >
> > >
> > > Thanks for your help!
> > >
> > > Rainer
> > >
> > >
> > > --

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Database access design question

[rainer juenger]

Sorry but I am in another galaxy as you guys are. My problems are not that
complex yet and my knowledge isn't either.
I would only like to have a simple sample how I can access the Database
defined in the struts-config.xml without having to use any servlet depending
methodes/classes  like pageContext, sessions or what so ever. There must be
a way!

thanks 1000 times for a hint!

Rainer

- Original Message -
From: "Jerry Jalenak" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, June 10, 2002 3:17 PM
Subject: RE: Database access design question


> I'm needing to move my data access from my Actions to a 'pure' business
> bean.  Does anyone have a good example (or link) on how to create and use
> DAO?
>
> Thanks.
>
> Jerry
>
> -Original Message-
> From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 3:43 AM
> To: Struts Users Mailing List
> Subject: RE: Database access design question
>
>
> 1. Do not use the session bean to access the datasource... create a data
> access object which locates the datasource.
> 2. Lookup the datasource using a jndi name not a servlet. Register your
> datasource with the jndi server. (Does the servlet api implement such a
> method ??)
> 3. If using a connection pool (which you should really), get the
connection
> object out of the pool and use it to access the database.
>
> HTH
> Vikram
>
>
> -Original Message-
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 2:04 PM
> To: Struts Users Mailing List
> Subject: Re: Database access design question
>
>
> I want to accesss the database from a business logic bean that should not
> emplement *.servelet.* classes.
> But how can I then initialize the DataSource?
> like: dataSource = servlet.findDataSource(null);
>
> ??
>
> Thanks Rainer
>
>
> > What exactly is your question?
> > The samples given with Struts do not necessarily following the best
> practices, they are more like proof of concepts than anything else.
> >
> > Rgs
> > Vikram
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 1:45 PM
> > To: Struts Users Mailing List
> > Subject: Database access design question
> >
> >
> > Hi,
> >
> > I am using the Struts Database pooling.
> > My database connection is realised after the sample in the Struts User's
> > Guide.
> > http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > But I think the sample is very contradicting.
> > In chapter 2.5 Business Logic Beans is said:
> > "For maximum code re-use, business logic beans should be designed and
> > implemented so that they do not know they are being executed in a web
> > application environment. If you find yourself having to import a
> > javax.servlet.* class in your bean, you are tying this business logic to
> the
> > web application environment. "
> >
> > but chapter 2.6 is Accessing the Database in the sample via a
> ActionServlet:
> > public ActionForward
> >perform(ActionMapping mapping,
> >ActionForm form,
> >HttpServletRequest request,
> >HttpServletResponse response)
> > {
> >  javax.sql.DataSource dataSource;
> >  java.sql.Connection myConnection;
> >
> >  try {
> >dataSource = servlet.findDataSource(null);
> >myConnection = dataSource.getConnection();
> >
> > Now I am pretty confused since I want to implement the Database Access
in
> a
> > buiseness logic bean.
> >
> >
> > Thanks for your help!
> >
> > Rainer
> >
> >
> > --
> > 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]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> This transmission (and any information attached to it) may be confidential
and is intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient or the person
responsible for delivering the transmission to the intended recipient, be
advised that you have received this transmission in error and that any use,
dissemination, forwarding, printing, or copying of this information is
strictly prohibited. If you have received this transmission in error, please
immediately notify LabOne at (800)388-4675.
>
>
>
> --
> 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]>

Re[2]: Database access design question

[Rick Reumann]

On Monday, June 10, 2002, 10:13:34 AM, wbchmura wrote:

wEBc> I took a quick look at the yahoo site - and will pursue that further, 
wEBc> but can you recommend any write-ups anywhere on this?

  I just went through the same struggles you are going through.
  Robert wrote up a great post that really helped clarify things
  for me. I'm trying the find the post now and I'll send it to
  you. (I have it saved at home and if I can't find it I'll send
  it to you later).

  Also be sure to check out Chuck's chapter 6 at this link:
  http://www.theserverside.com/resources/strutsreview.jsp

  Vic's webPIM application handles the architecture in a different
  way and you could find out more by downloading the sample app:
  http://www.basebeans.com/downloads.jsp

  I'll also send you what I came up with if you are interested
  (which for the most part follows the design principals Robert
  and Chuck helped me understand).

-- 

Rick
mailto:[EMAIL PROTECTED]

"Instead of studying for finals, what about just going to the Bahamas
and catching some rays? Maybe you'll flunk, but you might have flunked
anyway; that's my point." 
  -Jack Handey


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Database access design question

[Robert Taylor]

This is a subjective area. The Data Access Object is a design pattern which
really is
just a recommendation on how to implement access to the data store. There
are
several approaches, from home grown to commercial O/R products. Take a look
at Martin Fowlers site http://martinfowler.com/isa/index.html, Chuck
Caveness
book (chapter 6) http://www.theserverside.com/resources/strutsreview.jsp,
and then the archives are a great resource
http://www.mail-archive.com/struts-user%40jakarta.apache.org/.

HTH,

robert

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 10:14 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Database access design question
>
>
>
> Thanks for the feedback on that one.  No matter how I sliced that one I
> always had some kind of problem with how I was seperating everything
> up...
>
> I think the part that really confused me was that for this app, so far,
> there really is no business logic.  Its all lookups on the database...
>
> I took a quick look at the yahoo site - and will pursue that further,
> but can you recommend any write-ups anywhere on this?
>
> Thanks again...
>
>
>
>
> -Original Message-
> From: rtaylor [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 9:54 AM
> To: struts-user
> Subject: RE: Database access design question
>
>
> It sounds like your DAO is really a business object and your db object
> follows the DAO design pattern. I think you have the right concept
> though.
> You may want to check out http://groups.yahoo.com/group/model_struts/.
> It
> is dedicated to discussing the model layer using Struts.
>
> robert
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 9:39 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Database access design question
> >
> >
> >
> > I did something and I have been wondering if it is right...  So this
> may
> > be a good time.
> >
> > I have three levels in my model...  They look like
> >
> > Action (Struts action)
> > DAO object
> > Database object
> > Oracle DB
> >
> >
> > the action will call the DAO object along the lines of
> getCompanyList()
> > or somethig
> > The DAO then eastablishes a connection to a database and passes it to
> > the Database object
> > The Database object then does all of the SQL work to get the data
> back.
> >
> > Is this good or bad?
> >
> > As is, neither the DAO or the Database knows they are in a web
> > application.  The actual Database layer works in JDBC but does not
> have
> > any idea of the kind of JDBC database it is working in, only that it
> has
> > a connection passed to it.
> >
> > This could be wrong, if so ... Someone tell me!
> >
> > Thanks
> >
> >
> >
> > -Original Message-
> > From: jakarta.rainer [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 4:34 AM
> > To: struts-user
> > Subject: Re: Database access design question
> >
> >
> > I want to accesss the database from a business logic bean that should
> > not
> > emplement *.servelet.* classes.
> > But how can I then initialize the DataSource?
> > like: dataSource = servlet.findDataSource(null);
> >
> > ??
> >
> > Thanks Rainer
> >
> >
> > > What exactly is your question?
> > > The samples given with Struts do not necessarily following the best
> > practices, they are more like proof of concepts than anything else.
> > >
> > > Rgs
> > > Vikram
> > >
> > > -Original Message-
> > > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 10, 2002 1:45 PM
> > > To: Struts Users Mailing List
> > > Subject: Database access design question
> > >
> > >
> > > Hi,
> > >
> > > I am using the Struts Database pooling.
> > > My database connection is realised after the sample in the Struts
> > User's
> > > Guide.
> > >
> >
> http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > > But I think the sample is very contradicting.
> > > In chapter 2.5 Business Logic Beans is said:
> > > "For maximum code re-use, business logic beans should be designed
> and
> > > implemented so that they do not know they are being executed in a
> web
> > > application environment. If you find yourself having to import a
> > > javax.servle

RE: Database access design question

[wbchmura]

Thanks for the feedback on that one.  No matter how I sliced that one I 
always had some kind of problem with how I was seperating everything 
up...

I think the part that really confused me was that for this app, so far, 
there really is no business logic.  Its all lookups on the database... 

I took a quick look at the yahoo site - and will pursue that further, 
but can you recommend any write-ups anywhere on this?  

Thanks again...




-Original Message-
From: rtaylor [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 9:54 AM
To: struts-user
Subject: RE: Database access design question


It sounds like your DAO is really a business object and your db object
follows the DAO design pattern. I think you have the right concept 
though.
You may want to check out http://groups.yahoo.com/group/model_struts/. 
It
is dedicated to discussing the model layer using Struts.

robert

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 9:39 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Database access design question
>
>
>
> I did something and I have been wondering if it is right...  So this 
may
> be a good time.
>
> I have three levels in my model...  They look like
>
> Action (Struts action)
> DAO object
> Database object
> Oracle DB
>
>
> the action will call the DAO object along the lines of 
getCompanyList()
> or somethig
> The DAO then eastablishes a connection to a database and passes it to
> the Database object
> The Database object then does all of the SQL work to get the data 
back.
>
> Is this good or bad?
>
> As is, neither the DAO or the Database knows they are in a web
> application.  The actual Database layer works in JDBC but does not 
have
> any idea of the kind of JDBC database it is working in, only that it 
has
> a connection passed to it.
>
> This could be wrong, if so ... Someone tell me!
>
> Thanks
>
>
>
> -Original Message-
> From: jakarta.rainer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 4:34 AM
> To: struts-user
> Subject: Re: Database access design question
>
>
> I want to accesss the database from a business logic bean that should
> not
> emplement *.servelet.* classes.
> But how can I then initialize the DataSource?
> like: dataSource = servlet.findDataSource(null);
>
> ??
>
> Thanks Rainer
>
>
> > What exactly is your question?
> > The samples given with Struts do not necessarily following the best
> practices, they are more like proof of concepts than anything else.
> >
> > Rgs
> > Vikram
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 1:45 PM
> > To: Struts Users Mailing List
> > Subject: Database access design question
> >
> >
> > Hi,
> >
> > I am using the Struts Database pooling.
> > My database connection is realised after the sample in the Struts
> User's
> > Guide.
> >
> 
http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > But I think the sample is very contradicting.
> > In chapter 2.5 Business Logic Beans is said:
> > "For maximum code re-use, business logic beans should be designed 
and
> > implemented so that they do not know they are being executed in a 
web
> > application environment. If you find yourself having to import a
> > javax.servlet.* class in your bean, you are tying this business 
logic
> to
> the
> > web application environment. "
> >
> > but chapter 2.6 is Accessing the Database in the sample via a
> ActionServlet:
> > public ActionForward
> >perform(ActionMapping mapping,
> >ActionForm form,
> >HttpServletRequest request,
> >HttpServletResponse response)
> > {
> >  javax.sql.DataSource dataSource;
> >  java.sql.Connection myConnection;
> >
> >  try {
> >dataSource = servlet.findDataSource(null);
> >myConnection = dataSource.getConnection();
> >
> > Now I am pretty confused since I want to implement the Database 
Access
> in
> a
> > buiseness logic bean.
> >
> >
> > Thanks for your help!
> >
> > Rainer
> >
> >
> > --
> > 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]>
>
>
>
> --
> 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]>

RE: Database access design question

[Robert Taylor]

It sounds like your DAO is really a business object and your db object
follows the DAO design pattern. I think you have the right concept though.
You may want to check out http://groups.yahoo.com/group/model_struts/. It
is dedicated to discussing the model layer using Struts.

robert

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 9:39 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Database access design question
>
>
>
> I did something and I have been wondering if it is right...  So this may
> be a good time.
>
> I have three levels in my model...  They look like
>
> Action (Struts action)
> DAO object
> Database object
> Oracle DB
>
>
> the action will call the DAO object along the lines of getCompanyList()
> or somethig
> The DAO then eastablishes a connection to a database and passes it to
> the Database object
> The Database object then does all of the SQL work to get the data back.
>
> Is this good or bad?
>
> As is, neither the DAO or the Database knows they are in a web
> application.  The actual Database layer works in JDBC but does not have
> any idea of the kind of JDBC database it is working in, only that it has
> a connection passed to it.
>
> This could be wrong, if so ... Someone tell me!
>
> Thanks
>
>
>
> -Original Message-
> From: jakarta.rainer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 4:34 AM
> To: struts-user
> Subject: Re: Database access design question
>
>
> I want to accesss the database from a business logic bean that should
> not
> emplement *.servelet.* classes.
> But how can I then initialize the DataSource?
> like: dataSource = servlet.findDataSource(null);
>
> ??
>
> Thanks Rainer
>
>
> > What exactly is your question?
> > The samples given with Struts do not necessarily following the best
> practices, they are more like proof of concepts than anything else.
> >
> > Rgs
> > Vikram
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 1:45 PM
> > To: Struts Users Mailing List
> > Subject: Database access design question
> >
> >
> > Hi,
> >
> > I am using the Struts Database pooling.
> > My database connection is realised after the sample in the Struts
> User's
> > Guide.
> >
> http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > But I think the sample is very contradicting.
> > In chapter 2.5 Business Logic Beans is said:
> > "For maximum code re-use, business logic beans should be designed and
> > implemented so that they do not know they are being executed in a web
> > application environment. If you find yourself having to import a
> > javax.servlet.* class in your bean, you are tying this business logic
> to
> the
> > web application environment. "
> >
> > but chapter 2.6 is Accessing the Database in the sample via a
> ActionServlet:
> > public ActionForward
> >perform(ActionMapping mapping,
> >ActionForm form,
> >HttpServletRequest request,
> >HttpServletResponse response)
> > {
> >  javax.sql.DataSource dataSource;
> >  java.sql.Connection myConnection;
> >
> >  try {
> >dataSource = servlet.findDataSource(null);
> >myConnection = dataSource.getConnection();
> >
> > Now I am pretty confused since I want to implement the Database Access
> in
> a
> > buiseness logic bean.
> >
> >
> > Thanks for your help!
> >
> > Rainer
> >
> >
> > --
> > 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]>
>
>
>
> --
> 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]>

RE: Database access design question

[wbchmura]

I did something and I have been wondering if it is right...  So this may 
be a good time.

I have three levels in my model...  They look like

Action (Struts action)
DAO object 
Database object 
Oracle DB


the action will call the DAO object along the lines of getCompanyList() 
or somethig
The DAO then eastablishes a connection to a database and passes it to 
the Database object
The Database object then does all of the SQL work to get the data back.

Is this good or bad?

As is, neither the DAO or the Database knows they are in a web 
application.  The actual Database layer works in JDBC but does not have 
any idea of the kind of JDBC database it is working in, only that it has 
a connection passed to it. 

This could be wrong, if so ... Someone tell me!

Thanks



-Original Message-
From: jakarta.rainer [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 4:34 AM
To: struts-user
Subject: Re: Database access design question


I want to accesss the database from a business logic bean that should 
not
emplement *.servelet.* classes.
But how can I then initialize the DataSource?
like: dataSource = servlet.findDataSource(null);

??

Thanks Rainer


> What exactly is your question?
> The samples given with Struts do not necessarily following the best
practices, they are more like proof of concepts than anything else.
>
> Rgs
> Vikram
>
> -Original Message-
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 1:45 PM
> To: Struts Users Mailing List
> Subject: Database access design question
>
>
> Hi,
>
> I am using the Struts Database pooling.
> My database connection is realised after the sample in the Struts 
User's
> Guide.
> 
http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> But I think the sample is very contradicting.
> In chapter 2.5 Business Logic Beans is said:
> "For maximum code re-use, business logic beans should be designed and
> implemented so that they do not know they are being executed in a web
> application environment. If you find yourself having to import a
> javax.servlet.* class in your bean, you are tying this business logic 
to
the
> web application environment. "
>
> but chapter 2.6 is Accessing the Database in the sample via a
ActionServlet:
> public ActionForward
>perform(ActionMapping mapping,
>ActionForm form,
>HttpServletRequest request,
>HttpServletResponse response)
> {
>  javax.sql.DataSource dataSource;
>  java.sql.Connection myConnection;
>
>  try {
>dataSource = servlet.findDataSource(null);
>myConnection = dataSource.getConnection();
>
> Now I am pretty confused since I want to implement the Database Access 
in
a
> buiseness logic bean.
>
>
> Thanks for your help!
>
> Rainer
>
>
> --
> 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]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Database access design question

[Jerry Jalenak]

I'm needing to move my data access from my Actions to a 'pure' business
bean.  Does anyone have a good example (or link) on how to create and use
DAO?

Thanks.

Jerry

-Original Message-
From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 3:43 AM
To: Struts Users Mailing List
Subject: RE: Database access design question


1. Do not use the session bean to access the datasource... create a data
access object which locates the datasource.
2. Lookup the datasource using a jndi name not a servlet. Register your
datasource with the jndi server. (Does the servlet api implement such a
method ??)
3. If using a connection pool (which you should really), get the connection
object out of the pool and use it to access the database.

HTH
Vikram


-Original Message-
From: rainer juenger [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 2:04 PM
To: Struts Users Mailing List
Subject: Re: Database access design question


I want to accesss the database from a business logic bean that should not
emplement *.servelet.* classes.
But how can I then initialize the DataSource?
like: dataSource = servlet.findDataSource(null);

??

Thanks Rainer


> What exactly is your question?
> The samples given with Struts do not necessarily following the best
practices, they are more like proof of concepts than anything else.
>
> Rgs
> Vikram
>
> -Original Message- 
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 1:45 PM
> To: Struts Users Mailing List
> Subject: Database access design question
>
>
> Hi,
>
> I am using the Struts Database pooling.
> My database connection is realised after the sample in the Struts User's
> Guide.
> http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> But I think the sample is very contradicting.
> In chapter 2.5 Business Logic Beans is said:
> "For maximum code re-use, business logic beans should be designed and
> implemented so that they do not know they are being executed in a web
> application environment. If you find yourself having to import a
> javax.servlet.* class in your bean, you are tying this business logic to
the
> web application environment. "
>
> but chapter 2.6 is Accessing the Database in the sample via a
ActionServlet:
> public ActionForward
>perform(ActionMapping mapping,
>ActionForm form,
>HttpServletRequest request,
>HttpServletResponse response)
> {
>  javax.sql.DataSource dataSource;
>  java.sql.Connection myConnection;
>
>  try {
>dataSource = servlet.findDataSource(null);
>myConnection = dataSource.getConnection();
>
> Now I am pretty confused since I want to implement the Database Access in
a
> buiseness logic bean.
>
>
> Thanks for your help!
>
> Rainer
>
>
> --
> 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]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


This transmission (and any information attached to it) may be confidential and is 
intended solely for the use of the individual or entity to which it is addressed. If 
you are not the intended recipient or the person responsible for delivering the 
transmission to the intended recipient, be advised that you have received this 
transmission in error and that any use, dissemination, forwarding, printing, or 
copying of this information is strictly prohibited. If you have received this 
transmission in error, please immediately notify LabOne at (800)388-4675.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Database access design question

[rainer juenger]

I am not sure but can I use JNDI when I configure the data-sources within
the struts-config.xml like:
  

  
How else can I access the datasource?

thx Rainer


> 1. Do not use the session bean to access the datasource... create a data
access object which locates the datasource.
> 2. Lookup the datasource using a jndi name not a servlet. Register your
datasource with the jndi server. (Does the servlet api implement such a
method ??)
> 3. If using a connection pool (which you should really), get the
connection object out of the pool and use it to access the database.
>
> HTH
> Vikram
>
>
> -Original Message-
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 2:04 PM
> To: Struts Users Mailing List
> Subject: Re: Database access design question
>
>
> I want to accesss the database from a business logic bean that should not
> emplement *.servelet.* classes.
> But how can I then initialize the DataSource?
> like: dataSource = servlet.findDataSource(null);
>
> ??
>
> Thanks Rainer
>
>
> > What exactly is your question?
> > The samples given with Struts do not necessarily following the best
> practices, they are more like proof of concepts than anything else.
> >
> > Rgs
> > Vikram
> >
> > -Original Message-
> > From: rainer juenger [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 10, 2002 1:45 PM
> > To: Struts Users Mailing List
> > Subject: Database access design question
> >
> >
> > Hi,
> >
> > I am using the Struts Database pooling.
> > My database connection is realised after the sample in the Struts User's
> > Guide.
> > http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> > But I think the sample is very contradicting.
> > In chapter 2.5 Business Logic Beans is said:
> > "For maximum code re-use, business logic beans should be designed and
> > implemented so that they do not know they are being executed in a web
> > application environment. If you find yourself having to import a
> > javax.servlet.* class in your bean, you are tying this business logic to
> the
> > web application environment. "
> >
> > but chapter 2.6 is Accessing the Database in the sample via a
> ActionServlet:
> > public ActionForward
> >perform(ActionMapping mapping,
> >ActionForm form,
> >HttpServletRequest request,
> >HttpServletResponse response)
> > {
> >  javax.sql.DataSource dataSource;
> >  java.sql.Connection myConnection;
> >
> >  try {
> >dataSource = servlet.findDataSource(null);
> >myConnection = dataSource.getConnection();
> >
> > Now I am pretty confused since I want to implement the Database Access
in
> a
> > buiseness logic bean.
> >
> >
> > Thanks for your help!
> >
> > Rainer
> >
> >
> > --
> > 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]>
>
>
> --
> 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]>

RE: Database access design question

[Vikram Goyal01]

1. Do not use the session bean to access the datasource... create a data access object 
which locates the datasource.
2. Lookup the datasource using a jndi name not a servlet. Register your datasource 
with the jndi server. (Does the servlet api implement such a method ??)
3. If using a connection pool (which you should really), get the connection object out 
of the pool and use it to access the database.

HTH
Vikram


-Original Message-
From: rainer juenger [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 2:04 PM
To: Struts Users Mailing List
Subject: Re: Database access design question


I want to accesss the database from a business logic bean that should not
emplement *.servelet.* classes.
But how can I then initialize the DataSource?
like: dataSource = servlet.findDataSource(null);

??

Thanks Rainer


> What exactly is your question?
> The samples given with Struts do not necessarily following the best
practices, they are more like proof of concepts than anything else.
>
> Rgs
> Vikram
>
> -Original Message- 
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 1:45 PM
> To: Struts Users Mailing List
> Subject: Database access design question
>
>
> Hi,
>
> I am using the Struts Database pooling.
> My database connection is realised after the sample in the Struts User's
> Guide.
> http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> But I think the sample is very contradicting.
> In chapter 2.5 Business Logic Beans is said:
> "For maximum code re-use, business logic beans should be designed and
> implemented so that they do not know they are being executed in a web
> application environment. If you find yourself having to import a
> javax.servlet.* class in your bean, you are tying this business logic to
the
> web application environment. "
>
> but chapter 2.6 is Accessing the Database in the sample via a
ActionServlet:
> public ActionForward
>perform(ActionMapping mapping,
>ActionForm form,
>HttpServletRequest request,
>HttpServletResponse response)
> {
>  javax.sql.DataSource dataSource;
>  java.sql.Connection myConnection;
>
>  try {
>dataSource = servlet.findDataSource(null);
>myConnection = dataSource.getConnection();
>
> Now I am pretty confused since I want to implement the Database Access in
a
> buiseness logic bean.
>
>
> Thanks for your help!
>
> Rainer
>
>
> --
> 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]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Database access design question

[rainer juenger]

I want to accesss the database from a business logic bean that should not
emplement *.servelet.* classes.
But how can I then initialize the DataSource?
like: dataSource = servlet.findDataSource(null);

??

Thanks Rainer


> What exactly is your question?
> The samples given with Struts do not necessarily following the best
practices, they are more like proof of concepts than anything else.
>
> Rgs
> Vikram
>
> -Original Message-
> From: rainer juenger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 1:45 PM
> To: Struts Users Mailing List
> Subject: Database access design question
>
>
> Hi,
>
> I am using the Struts Database pooling.
> My database connection is realised after the sample in the Struts User's
> Guide.
> http://jakarta.apache.org/struts/userGuide/building_model.html#databases
> But I think the sample is very contradicting.
> In chapter 2.5 Business Logic Beans is said:
> "For maximum code re-use, business logic beans should be designed and
> implemented so that they do not know they are being executed in a web
> application environment. If you find yourself having to import a
> javax.servlet.* class in your bean, you are tying this business logic to
the
> web application environment. "
>
> but chapter 2.6 is Accessing the Database in the sample via a
ActionServlet:
> public ActionForward
>perform(ActionMapping mapping,
>ActionForm form,
>HttpServletRequest request,
>HttpServletResponse response)
> {
>  javax.sql.DataSource dataSource;
>  java.sql.Connection myConnection;
>
>  try {
>dataSource = servlet.findDataSource(null);
>myConnection = dataSource.getConnection();
>
> Now I am pretty confused since I want to implement the Database Access in
a
> buiseness logic bean.
>
>
> Thanks for your help!
>
> Rainer
>
>
> --
> 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]>

RE: Database access design question

[Vikram Goyal01]

What exactly is your question? 
The samples given with Struts do not necessarily following the best practices, they 
are more like proof of concepts than anything else.

Rgs
Vikram

-Original Message-
From: rainer juenger [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 1:45 PM
To: Struts Users Mailing List
Subject: Database access design question


Hi,

I am using the Struts Database pooling.
My database connection is realised after the sample in the Struts User's
Guide.
http://jakarta.apache.org/struts/userGuide/building_model.html#databases
But I think the sample is very contradicting.
In chapter 2.5 Business Logic Beans is said:
"For maximum code re-use, business logic beans should be designed and
implemented so that they do not know they are being executed in a web
application environment. If you find yourself having to import a
javax.servlet.* class in your bean, you are tying this business logic to the
web application environment. "

but chapter 2.6 is Accessing the Database in the sample via a ActionServlet:
public ActionForward
   perform(ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
{
 javax.sql.DataSource dataSource;
 java.sql.Connection myConnection;

 try {
   dataSource = servlet.findDataSource(null);
   myConnection = dataSource.getConnection();

Now I am pretty confused since I want to implement the Database Access in a
buiseness logic bean.


Thanks for your help!

Rainer


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

Database access design question

[rainer juenger]

Hi,

I am using the Struts Database pooling.
My database connection is realised after the sample in the Struts User's
Guide.
http://jakarta.apache.org/struts/userGuide/building_model.html#databases
But I think the sample is very contradicting.
In chapter 2.5 Business Logic Beans is said:
"For maximum code re-use, business logic beans should be designed and
implemented so that they do not know they are being executed in a web
application environment. If you find yourself having to import a
javax.servlet.* class in your bean, you are tying this business logic to the
web application environment. "

but chapter 2.6 is Accessing the Database in the sample via a ActionServlet:
public ActionForward
   perform(ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
{
 javax.sql.DataSource dataSource;
 java.sql.Connection myConnection;

 try {
   dataSource = servlet.findDataSource(null);
   myConnection = dataSource.getConnection();

Now I am pretty confused since I want to implement the Database Access in a
buiseness logic bean.


Thanks for your help!

Rainer


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Mark Nichols]

From: "Yaman Kumar" <[EMAIL PROTECTED]>

> I have a AformBean in A.jsp and the page action is actionA, actionA
> processed
> all AfromBean values and got some dynamic data from Database,Now i
> would like to keep this data in BFormBean and the actionA forwards the
> output to B.jsp  how to keep the data in BformBean and how to populate
them
> in B.jsp?.
>

This is just a stab in the dark, but I think you need to create an instance
of BFormBean in actionA, and populate it yourself with whatever data it
holds. Then, before forwarding to B.jsp, you need to set BFormBean in the
appropriate scope (session or request) as defined in your struts-config.xml
file.

mark n.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Struts Design question

[Yaman Kumar]

Hi,
I have a design question of struts implementation in my application,

I have a AformBean in A.jsp and the page action is actionA, actionA
processed
all AfromBean values and got some dynamic data from Database,Now i
would like to keep this data in BFormBean and the actionA forwards the
output to B.jsp  how to keep the data in BformBean and how to populate them
in B.jsp?.

As when I requested form in actionA it is giving AformBean so i processed
all values them and got dynamic data and now
i would like to keep data in BFormBean, but i can't get
the reference of it. So how can i achieve?.

Can any one help me out?
TIA
rayaku


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts + Tiles: Design Question

[Cedric Dumoulin]

  Hello,

  You can have the ... tag in a common tiles ancestor inserting 
sub-tiles. Each sub-tiles can have tags like  or . There is an 
example of
that in tiles documentation (tiles-doc/tutorial/invoice/*.jsp). In this example, 
editInvoice.jsp declare the form, and then insert editAddress.jsp which  use 
.

  Hope this help,
   Cedric

Sri Sankaran wrote:

>   I am unable to use a common ancestor because some tags (such as , 
>) >must< be nested in a form and it doesn't recognize that this is indeed 
>the case:
>
>   Layout-Begin
> 
>   ..
>   Body-Tile-Begin
> 
>   Body-Tile-End
>   ..
>   Nav-Tile-Begin
> Previous-button
> Next-button
> ..
>   Nav-Tile-End
> 
>   Layout-End
>
>   So, I am >forced< to have the form tag in the Body-Tile.  Even then I am forced to 
>use JavaScript to indicate >which< of the buttons in the Nav-Tile was pressed.
>
>   Could you elaborate on >how< you workaround it?
>
> Sri
>
> -Original Message-
> From: Trieu, Danny [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 11:33 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Struts + Tiles: Design Question
>
> Cedric,
>
> You are right on the point.  I been using this strategies over and over
> again to share from amon difference action.  I works well for me, plus I
> really hate having JavaScript or hidden field to indicate which action your
> are intended to submit.   I think this is the right way to do cuz you really
> do separate the controller logic from presentation logic, or you can say ..
> hidding the controller logic by abstracting the presentation.
>
> danny
>
> > -Original Message-----
> > From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, May 24, 2002 3:19 AM
> > To:   Struts Users Mailing List
> > Subject:  Re: Struts + Tiles: Design Question
> >
> >
> >
> >   There is several strategies.
> >   Are you sure that you need one single form for navigation and body ?
> >
> >*   If  navigation and body aren't related, you can put several forms,
> > only one will be selected by browser when submitting.
> >*   If navigation and body are related, you need a common ancestor in
> > the Tiles philosophy. A common ancestor is a tiles that will insert
> > related sub-tiles. This ancestor contains the form, and sub-tiles contains
> > form's elements.
> >  In your case, you can have an ancestor body playing this role, and
> > inserting the navigation and real body
> >
> >   Hope this help,
> >
> > Cedric
> >
> > Sri Sankaran wrote:
> >
> > > Struts version: 1.0.2
> > > Servlet engine: Tomcat 4.0.2
> > >
> > > I am trying to build a wizard framework using Tiles.  It follows the
> > standard Windows wizard metaphor with a body panel and navigation buttons
> > below.  I am running into a problem and would like any
> > opinions/suggestions.
> > >
> > > A logical use of Tiles would call for the body and nav buttons to be
> > separate tiles that are combined using the tileDefinitions file.  For
> > example:
> > >
> > >   
> > > 
> > > 
> > > 
> > >   
> > >
> > >   
> > >   
> > > 
> > >   
> > >
> > > Here, the wizardLayout.jsp is solely responsible, as the name suggests,
> > for laying out the various tiles using necessary HTML tags.
> > >
> > > The problem with this strategy is that by separating the body and nav
> > into separate tiles limits the use of the Struts  tag.
> > Firstly, the begin and end form tag must be in the same JSP.  This
> > prevents the tag from beginning in the 'body' tile and ending in the
> > 'navigation' tile.  There are other complications, even if I'm willing to
> > compromise the design and place the  tag in the layout page
> > (wizardLayout.jsp above).  This would require some convoluted JavaScript
> > that sets the form's action attribute on each page.
> > >
> > > The only workaround I have found is to have the body & the navigation in
> > the same tile; in other words -- not have a 'navigation' tile at all.
> > This has a serious shortcoming in that it forces every body panel (i.e.
> > every page in the wizard) to have knowledge of layout and therefore
> > responsible for its maintenance.
> > >
> > > I really like the concept of Tiles and would love to use it to it

RE: Struts + Tiles: Design Question

[Trieu, Danny]

Ahaaa.. ic what you are trying to do.  What I was saying is that you can
have multiple page that share teh same from and each page submit the a
different action ... for example ...the CRUD ...'C'-create and 'U'-update,
are to different page that share the same from.. where as in you case it
is different ... you are actualy only have one page and one form so there is
no need to have a common ancestor all you need is to have a hidden field
that indicate whether your form submition is 'Prev' or 'Next' and have your
nav button modify this hidden field before submittion.

> -Original Message-
> From: Sri Sankaran [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 9:37 AM
> To:   'Struts Users Mailing List'
> Subject:  RE: Struts + Tiles: Design Question
> 
> 
>   I am unable to use a common ancestor because some tags (such as
> , ) >must< be nested in a form and it doesn't
> recognize that this is indeed the case:
> 
>   Layout-Begin
> 
>   ..
>   Body-Tile-Begin
> 
>   Body-Tile-End
>   ..
>   Nav-Tile-Begin
> Previous-button
> Next-button
> ..
>   Nav-Tile-End
> 
>   Layout-End
> 
>   So, I am >forced< to have the form tag in the Body-Tile.  Even then I am
> forced to use JavaScript to indicate >which< of the buttons in the
> Nav-Tile was pressed.
> 
>   Could you elaborate on >how< you workaround it?
> 
> Sri
> 
> -Original Message-
> From: Trieu, Danny [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 11:33 AM
> To: 'Struts Users Mailing List'
> Subject: RE: Struts + Tiles: Design Question
> 
> 
> Cedric,
> 
> You are right on the point.  I been using this strategies over and over
> again to share from amon difference action.  I works well for me, plus I
> really hate having JavaScript or hidden field to indicate which action
> your
> are intended to submit.   I think this is the right way to do cuz you
> really
> do separate the controller logic from presentation logic, or you can say
> ..
> hidding the controller logic by abstracting the presentation.
> 
> danny
> 
> > -Original Message-
> > From:   Cedric Dumoulin [SMTP:[EMAIL PROTECTED]]
> > Sent:   Friday, May 24, 2002 3:19 AM
> > To: Struts Users Mailing List
> > Subject:Re: Struts + Tiles: Design Question
> > 
> > 
> > 
> >   There is several strategies.
> >   Are you sure that you need one single form for navigation and body ?
> > 
> >*   If  navigation and body aren't related, you can put several
> forms,
> > only one will be selected by browser when submitting.
> >*   If navigation and body are related, you need a common ancestor in
> > the Tiles philosophy. A common ancestor is a tiles that will insert
> > related sub-tiles. This ancestor contains the form, and sub-tiles
> contains
> > form's elements.
> >  In your case, you can have an ancestor body playing this role, and
> > inserting the navigation and real body
> > 
> >   Hope this help,
> > 
> > Cedric
> > 
> > Sri Sankaran wrote:
> > 
> > > Struts version: 1.0.2
> > > Servlet engine: Tomcat 4.0.2
> > >
> > > I am trying to build a wizard framework using Tiles.  It follows the
> > standard Windows wizard metaphor with a body panel and navigation
> buttons
> > below.  I am running into a problem and would like any
> > opinions/suggestions.
> > >
> > > A logical use of Tiles would call for the body and nav buttons to be
> > separate tiles that are combined using the tileDefinitions file.  For
> > example:
> > >
> > >   
> > > 
> > > 
> > > 
> > >   
> > >
> > >   
> > >   
> > > 
> > >   
> > >
> > > Here, the wizardLayout.jsp is solely responsible, as the name
> suggests,
> > for laying out the various tiles using necessary HTML tags.
> > >
> > > The problem with this strategy is that by separating the body and nav
> > into separate tiles limits the use of the Struts  tag.
> > Firstly, the begin and end form tag must be in the same JSP.  This
> > prevents the tag from beginning in the 'body' tile and ending in the
> > 'navigation' tile.  There are other complications, even if I'm willing
> to
> > compromise the design and place the  tag in the layout page
> > (wizardLayout.jsp above).  This would require some convoluted Jav

RE: Struts + Tiles: Design Question

[Sri Sankaran]

  I am unable to use a common ancestor because some tags (such as , 
) >must< be nested in a form and it doesn't recognize that this is indeed 
the case:

  Layout-Begin

  ..
  Body-Tile-Begin

  Body-Tile-End
  ..
  Nav-Tile-Begin
Previous-button
Next-button
..
  Nav-Tile-End

  Layout-End

  So, I am >forced< to have the form tag in the Body-Tile.  Even then I am forced to 
use JavaScript to indicate >which< of the buttons in the Nav-Tile was pressed.

  Could you elaborate on >how< you workaround it?

Sri

-Original Message-
From: Trieu, Danny [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 24, 2002 11:33 AM
To: 'Struts Users Mailing List'
Subject: RE: Struts + Tiles: Design Question


Cedric,

You are right on the point.  I been using this strategies over and over
again to share from amon difference action.  I works well for me, plus I
really hate having JavaScript or hidden field to indicate which action your
are intended to submit.   I think this is the right way to do cuz you really
do separate the controller logic from presentation logic, or you can say ..
hidding the controller logic by abstracting the presentation.

danny

> -Original Message-
> From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 3:19 AM
> To:   Struts Users Mailing List
> Subject:  Re: Struts + Tiles: Design Question
> 
> 
> 
>   There is several strategies.
>   Are you sure that you need one single form for navigation and body ?
> 
>*   If  navigation and body aren't related, you can put several forms,
> only one will be selected by browser when submitting.
>*   If navigation and body are related, you need a common ancestor in
> the Tiles philosophy. A common ancestor is a tiles that will insert
> related sub-tiles. This ancestor contains the form, and sub-tiles contains
> form's elements.
>  In your case, you can have an ancestor body playing this role, and
> inserting the navigation and real body
> 
>   Hope this help,
> 
> Cedric
> 
> Sri Sankaran wrote:
> 
> > Struts version: 1.0.2
> > Servlet engine: Tomcat 4.0.2
> >
> > I am trying to build a wizard framework using Tiles.  It follows the
> standard Windows wizard metaphor with a body panel and navigation buttons
> below.  I am running into a problem and would like any
> opinions/suggestions.
> >
> > A logical use of Tiles would call for the body and nav buttons to be
> separate tiles that are combined using the tileDefinitions file.  For
> example:
> >
> >   
> > 
> > 
> > 
> >   
> >
> >   
> >   
> > 
> >   
> >
> > Here, the wizardLayout.jsp is solely responsible, as the name suggests,
> for laying out the various tiles using necessary HTML tags.
> >
> > The problem with this strategy is that by separating the body and nav
> into separate tiles limits the use of the Struts  tag.
> Firstly, the begin and end form tag must be in the same JSP.  This
> prevents the tag from beginning in the 'body' tile and ending in the
> 'navigation' tile.  There are other complications, even if I'm willing to
> compromise the design and place the  tag in the layout page
> (wizardLayout.jsp above).  This would require some convoluted JavaScript
> that sets the form's action attribute on each page.
> >
> > The only workaround I have found is to have the body & the navigation in
> the same tile; in other words -- not have a 'navigation' tile at all.
> This has a serious shortcoming in that it forces every body panel (i.e.
> every page in the wizard) to have knowledge of layout and therefore
> responsible for its maintenance.
> >
> > I really like the concept of Tiles and would love to use it to its
> fullest.  Do you have any suggestions?  Am I missing something
> fundamental?
> >
> >
> > Sri
> >
> > --
> > 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]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Struts + Tiles: Design Question

[Trieu, Danny]

Cedric,

You are right on the point.  I been using this strategies over and over
again to share from amon difference action.  I works well for me, plus I
really hate having JavaScript or hidden field to indicate which action your
are intended to submit.   I think this is the right way to do cuz you really
do separate the controller logic from presentation logic, or you can say ..
hidding the controller logic by abstracting the presentation.

danny

> -Original Message-
> From: Cedric Dumoulin [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 3:19 AM
> To:   Struts Users Mailing List
> Subject:  Re: Struts + Tiles: Design Question
> 
> 
> 
>   There is several strategies.
>   Are you sure that you need one single form for navigation and body ?
> 
>*   If  navigation and body aren't related, you can put several forms,
> only one will be selected by browser when submitting.
>*   If navigation and body are related, you need a common ancestor in
> the Tiles philosophy. A common ancestor is a tiles that will insert
> related sub-tiles. This ancestor contains the form, and sub-tiles contains
> form's elements.
>  In your case, you can have an ancestor body playing this role, and
> inserting the navigation and real body
> 
>   Hope this help,
> 
> Cedric
> 
> Sri Sankaran wrote:
> 
> > Struts version: 1.0.2
> > Servlet engine: Tomcat 4.0.2
> >
> > I am trying to build a wizard framework using Tiles.  It follows the
> standard Windows wizard metaphor with a body panel and navigation buttons
> below.  I am running into a problem and would like any
> opinions/suggestions.
> >
> > A logical use of Tiles would call for the body and nav buttons to be
> separate tiles that are combined using the tileDefinitions file.  For
> example:
> >
> >   
> > 
> > 
> > 
> >   
> >
> >   
> >   
> > 
> >   
> >
> > Here, the wizardLayout.jsp is solely responsible, as the name suggests,
> for laying out the various tiles using necessary HTML tags.
> >
> > The problem with this strategy is that by separating the body and nav
> into separate tiles limits the use of the Struts  tag.
> Firstly, the begin and end form tag must be in the same JSP.  This
> prevents the tag from beginning in the 'body' tile and ending in the
> 'navigation' tile.  There are other complications, even if I'm willing to
> compromise the design and place the  tag in the layout page
> (wizardLayout.jsp above).  This would require some convoluted JavaScript
> that sets the form's action attribute on each page.
> >
> > The only workaround I have found is to have the body & the navigation in
> the same tile; in other words -- not have a 'navigation' tile at all.
> This has a serious shortcoming in that it forces every body panel (i.e.
> every page in the wizard) to have knowledge of layout and therefore
> responsible for its maintenance.
> >
> > I really like the concept of Tiles and would love to use it to its
> fullest.  Do you have any suggestions?  Am I missing something
> fundamental?
> >
> >
> > Sri
> >
> > --
> > 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]>

Re: Struts + Tiles: Design Question

[Cedric Dumoulin]

  There is several strategies.
  Are you sure that you need one single form for navigation and body ?

   *   If  navigation and body aren't related, you can put several forms, only one 
will be selected by browser when submitting.
   *   If navigation and body are related, you need a common ancestor in the Tiles 
philosophy. A common ancestor is a tiles that will insert related sub-tiles. This 
ancestor contains the form, and sub-tiles contains form's elements.
 In your case, you can have an ancestor body playing this role, and inserting the 
navigation and real body

  Hope this help,

Cedric

Sri Sankaran wrote:

> Struts version: 1.0.2
> Servlet engine: Tomcat 4.0.2
>
> I am trying to build a wizard framework using Tiles.  It follows the standard 
>Windows wizard metaphor with a body panel and navigation buttons below.  I am running 
>into a problem and would like any opinions/suggestions.
>
> A logical use of Tiles would call for the body and nav buttons to be separate tiles 
>that are combined using the tileDefinitions file.  For example:
>
>   
> 
> 
> 
>   
>
>   
>   
> 
>   
>
> Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying 
>out the various tiles using necessary HTML tags.
>
> The problem with this strategy is that by separating the body and nav into separate 
>tiles limits the use of the Struts  tag.  Firstly, the begin and end form 
>tag must be in the same JSP.  This prevents the tag from beginning in the 'body' tile 
>and ending in the 'navigation' tile.  There are other complications, even if I'm 
>willing to compromise the design and place the  tag in the layout page 
>(wizardLayout.jsp above).  This would require some convoluted JavaScript that sets 
>the form's action attribute on each page.
>
> The only workaround I have found is to have the body & the navigation in the same 
>tile; in other words -- not have a 'navigation' tile at all.  This has a serious 
>shortcoming in that it forces every body panel (i.e. every page in the wizard) to 
>have knowledge of layout and therefore responsible for its maintenance.
>
> I really like the concept of Tiles and would love to use it to its fullest.  Do you 
>have any suggestions?  Am I missing something fundamental?
>
>
> Sri
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts + Tiles: Design Question

[Sri Sankaran]

Graham:
  JavaScript does present an alternative.

  The problem I have with JavaScript in the Struts context is that it tightly couples 
the contents of the struts-config to the JSP.  For example, to submit the form, you 
have to know the name of the form (unless you have just one or can make other 
simplifying assumptions).  The name of the form itself is driven by the 'name' 
attribute of the action-mapping element in the struts-config.

  Having said that, this may be the lesser of two evils.  I just have to remember if 
any mapping information changes to make sure that related pages are modified as well.

  Thanks

Sri

-Original Message-
From: Graham Lounder [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 2:07 PM
To: Struts Users Mailing List
Subject: Re: Struts + Tiles: Design Question


Just a quick suggestion.  Couldn't you use javascript in your nav.jsp to
submit the form in the intro.jsp?  Or do you need form fields in the
nav.jsp?

Graham

- Original Message -
From: "Sri Sankaran" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 22, 2002 2:53 PM
Subject: Struts + Tiles: Design Question


> Struts version: 1.0.2
> Servlet engine: Tomcat 4.0.2
>
> I am trying to build a wizard framework using Tiles.  It follows the
standard Windows wizard metaphor with a body panel and navigation buttons
below.  I am running into a problem and would like any opinions/suggestions.
>
> A logical use of Tiles would call for the body and nav buttons to be
separate tiles that are combined using the tileDefinitions file.  For
example:
>
>   
> 
> 
> 
>   
>
>   
>   
> 
>   
>
> Here, the wizardLayout.jsp is solely responsible, as the name suggests,
for laying out the various tiles using necessary HTML tags.
>
> The problem with this strategy is that by separating the body and nav into
separate tiles limits the use of the Struts  tag.  Firstly, the
begin and end form tag must be in the same JSP.  This prevents the tag from
beginning in the 'body' tile and ending in the 'navigation' tile.  There are
other complications, even if I'm willing to compromise the design and place
the  tag in the layout page (wizardLayout.jsp above).  This would
require some convoluted JavaScript that sets the form's action attribute on
each page.
>
> The only workaround I have found is to have the body & the navigation in
the same tile; in other words -- not have a 'navigation' tile at all.  This
has a serious shortcoming in that it forces every body panel (i.e. every
page in the wizard) to have knowledge of layout and therefore responsible
for its maintenance.
>
> I really like the concept of Tiles and would love to use it to its
fullest.  Do you have any suggestions?  Am I missing something fundamental?
>
>
> Sri
>
> --
> 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]>

Re: Struts + Tiles: Design Question

[Graham Lounder]

Just a quick suggestion.  Couldn't you use javascript in your nav.jsp to
submit the form in the intro.jsp?  Or do you need form fields in the
nav.jsp?

Graham

- Original Message -
From: "Sri Sankaran" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 22, 2002 2:53 PM
Subject: Struts + Tiles: Design Question


> Struts version: 1.0.2
> Servlet engine: Tomcat 4.0.2
>
> I am trying to build a wizard framework using Tiles.  It follows the
standard Windows wizard metaphor with a body panel and navigation buttons
below.  I am running into a problem and would like any opinions/suggestions.
>
> A logical use of Tiles would call for the body and nav buttons to be
separate tiles that are combined using the tileDefinitions file.  For
example:
>
>   
> 
> 
> 
>   
>
>   
>   
> 
>   
>
> Here, the wizardLayout.jsp is solely responsible, as the name suggests,
for laying out the various tiles using necessary HTML tags.
>
> The problem with this strategy is that by separating the body and nav into
separate tiles limits the use of the Struts  tag.  Firstly, the
begin and end form tag must be in the same JSP.  This prevents the tag from
beginning in the 'body' tile and ending in the 'navigation' tile.  There are
other complications, even if I'm willing to compromise the design and place
the  tag in the layout page (wizardLayout.jsp above).  This would
require some convoluted JavaScript that sets the form's action attribute on
each page.
>
> The only workaround I have found is to have the body & the navigation in
the same tile; in other words -- not have a 'navigation' tile at all.  This
has a serious shortcoming in that it forces every body panel (i.e. every
page in the wizard) to have knowledge of layout and therefore responsible
for its maintenance.
>
> I really like the concept of Tiles and would love to use it to its
fullest.  Do you have any suggestions?  Am I missing something fundamental?
>
>
> Sri
>
> --
> 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]>

Struts + Tiles: Design Question

[Sri Sankaran]

Struts version: 1.0.2
Servlet engine: Tomcat 4.0.2

I am trying to build a wizard framework using Tiles.  It follows the standard Windows 
wizard metaphor with a body panel and navigation buttons below.  I am running into a 
problem and would like any opinions/suggestions.

A logical use of Tiles would call for the body and nav buttons to be separate tiles 
that are combined using the tileDefinitions file.  For example:

  



  

  
  

  

Here, the wizardLayout.jsp is solely responsible, as the name suggests, for laying out 
the various tiles using necessary HTML tags.

The problem with this strategy is that by separating the body and nav into separate 
tiles limits the use of the Struts  tag.  Firstly, the begin and end form 
tag must be in the same JSP.  This prevents the tag from beginning in the 'body' tile 
and ending in the 'navigation' tile.  There are other complications, even if I'm 
willing to compromise the design and place the  tag in the layout page 
(wizardLayout.jsp above).  This would require some convoluted JavaScript that sets the 
form's action attribute on each page.

The only workaround I have found is to have the body & the navigation in the same 
tile; in other words -- not have a 'navigation' tile at all.  This has a serious 
shortcoming in that it forces every body panel (i.e. every page in the wizard) to have 
knowledge of layout and therefore responsible for its maintenance.

I really like the concept of Tiles and would love to use it to its fullest.  Do you 
have any suggestions?  Am I missing something fundamental?
 

Sri

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Struts Tag Design Question

[Galbreath, Mark]

And I simply overlooking a parameter of a particular tag, or is there no way
to test a boolean "isXxxx" method with a Struts tag?  Is the 
the best we have (due to the reliance upon beans)?
 
Mark

RE: Design question on roles and tasks

[Jon.Ridgway]

Hi Chong,

Container based security is a topic that comes up regularly on the list try
searching on it. 

When you use container based security your authenticated user will be
associated with one or more roles. This is a J2EE feature.

Struts can use the 'role' information in several ways:

- the tile and template extensions provide a 'role' tag to conditionally
include content depending upon a users role.

- within your action class your can call request.isUserInRole () and
execute code depending on the result.

- within the struts-config you can set a role against an action-mapping so
that only users in the given role can access the action. Never used this
feature so I'm not sure what happens if the user is not in the role.

Jon Ridgway

-Original Message-
From: Chong Oh [mailto:[EMAIL PROTECTED]] 
Sent: 08 May 2002 21:10
To: 'Struts Users Mailing List'
Subject: Design question on roles and tasks

All:

If this has been discussed already, I apologize.  I am implementing an user
access based on roles and tasks, where a user has roles and each role has
tasks.  Ideally, each task has a one to one relationship with each link on
the JSP, whereby the access to those links depends on user's role/s.  All
roles and tasks are persisted.

Upon successful login, user's roles will be accessed and all tasks
associated will be retrieved.  All links associated with tasks will be shown
on the JSP via logic tags.

Has anyone implement this with struts yet.  Could you share your experience
with me, particularly the question whether this is a good design in the
first place?

Thanks in advance

Chong

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

The contents of this email are intended only for the named addressees and
may contain confidential and/or privileged material. If received in error
please contact UPCO on +44 (0) 113 201 0600 and then delete the entire
e-mail from your system. Unauthorised review, distribution, disclosure or
other use of this information could constitute a breach of confidence. Your
co-operation in this matter is greatly appreciated. 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Design question

[Will Spies/Towers Perrin]

Thanks for all the ideas. Looks like my best option is , as was suggested,
to place all JSPs below WEB-INF. This way they are invisible to the browser
but visible to the struts forwarding mechanism. In addition, I can then
create a tag to do some extra checking as you suggest.

Thanks to all again!



___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


   

   

   To:   "Struts Users Mailing List" 
<[EMAIL PROTECTED]>  
  Kevin.Bedell@sunlcc:   (bcc: Will Spies/Towers 
Perrin)   
  ife.com  Subject:  Re: Design question   

   

  04/30/02 08:10 AM

  Please respond to

  "Struts Users

  Mailing List"

   

   








If you're using Apache, create a rewrite rule that rewrites anything ending
in .jsp to .do.

Or a rewrite rule that filters only URI's in your webapp and forwards them
to a home page if a .jsp is requested.

I don't think there can be a Struts'only solution. The issue is that any
URI ending in .jsp could be requested - Struts works by recognizing certain
URI's (those specified by the definition of the primary Action servlet in
yout web.xml), and routing them to the central Action servlet for
processing.

If a URI is requested (ending in jsp or not) that doesn't match the URI
pattern for the Action servlet, then Struts won't even see it.

A generic jsp approach might be to create a custom tag (like,
 or something similar) that looks for a bean or
something similar that should be
in the Session. If it's not there then redirect to a home page or
something.






"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 04:08:04 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Re: Design question




Good idea but the other problem is your web server doesn't mix with
non-Struts applications. I was kinda hoping for a struts only solution.
Thanks for the idea though!


___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]




   To:   "Struts Users
Mailing List" <[EMAIL PROTECTED]>
      Kevin.Bedell@sunlcc:   (bcc: Will
Spies/Towers Perrin)
  ife.com  Subject:  Re: Design
question

  04/29/02 03:51 PM
  Please respond to
  "Struts Users
  Mailing List"









Configure the web server to not recognize the .jsp mime type.  Then any
link to a .jsp page will generate an "Error 404 Page Not Found". The
servlet mappings should still work fine.

That being said, I've found that whenever I make a decision like this based
on a design preference, I almost always find some unusual case where it
really makes sense to do things the way I've said shouldn't be done.


FWIW -
Kevin







"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Design question





In my opinion, most ( if not all ) links should be Action URIs. What I mean
is, struts views should not post to urls which are JSP struts views.
Rather, valid URLs that are post

Re: Design question

[Kevin . Bedell]

If you're using Apache, create a rewrite rule that rewrites anything ending
in .jsp to .do.

Or a rewrite rule that filters only URI's in your webapp and forwards them
to a home page if a .jsp is requested.

I don't think there can be a Struts'only solution. The issue is that any
URI ending in .jsp could be requested - Struts works by recognizing certain
URI's (those specified by the definition of the primary Action servlet in
yout web.xml), and routing them to the central Action servlet for
processing.

If a URI is requested (ending in jsp or not) that doesn't match the URI
pattern for the Action servlet, then Struts won't even see it.

A generic jsp approach might be to create a custom tag (like,
 or something similar) that looks for a bean or
something similar that should be
in the Session. If it's not there then redirect to a home page or
something.






"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 04:08:04 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Re: Design question




Good idea but the other problem is your web server doesn't mix with
non-Struts applications. I was kinda hoping for a struts only solution.
Thanks for the idea though!


___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]




   To:   "Struts Users
Mailing List" <[EMAIL PROTECTED]>
  Kevin.Bedell@sunl    cc:   (bcc: Will
Spies/Towers Perrin)
  ife.com  Subject:  Re: Design
question

  04/29/02 03:51 PM
  Please respond to
  "Struts Users
  Mailing List"









Configure the web server to not recognize the .jsp mime type.  Then any
link to a .jsp page will generate an "Error 404 Page Not Found". The
servlet mappings should still work fine.

That being said, I've found that whenever I make a decision like this based
on a design preference, I almost always find some unusual case where it
really makes sense to do things the way I've said shouldn't be done.


FWIW -
Kevin







"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Design question





In my opinion, most ( if not all ) links should be Action URIs. What I mean
is, struts views should not post to urls which are JSP struts views.
Rather, valid URLs that are posted to ( or even referenced in ) should
always be controllers. For those who agree with this philosophy, can you
give me some suggestions on how I can force this? One idea I've had is to
place a customized on top of all JSP views which checks for a hidden
request variable that only my controllers know about. So, if this request
variable is not found than the view craps out. Any other ideas?



___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---


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







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communi

RE: Design question

[Amir Nashat]

Couldn't you just configure your web.xml file to map all .jsp requests to some 
standard error page? 

amir



>>> [EMAIL PROTECTED] 6:02:54 PM 04/29/02 >>>
Or

you could put your jsp's under the WEB-INF directory.

Search posts from a few weeks ago about this.
It's quite a lengthy and enlightening thread.


JM

> -Original Message-
> From: Will Spies/Towers Perrin [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, April 29, 2002 4:08 PM
> To: Struts Users Mailing List
> Subject: Re: Design question
>
>
>
>
> Good idea but the other problem is your web server doesn't mix with
> non-Struts applications. I was kinda hoping for a struts only solution.
> Thanks for the idea though!
>
>
> ___
> Will Spies
> Towers Perrin
> Phone: (215)246-7145
> e-mail: [EMAIL PROTECTED] 
>
>
>
>
>
>
>To:   "Struts
> Users Mailing List" <[EMAIL PROTECTED]>
>   Kevin.Bedell@sunlcc:   (bcc:
> Will Spies/Towers Perrin)
>   ife.com  Subject:  Re:
> Design question
>
>
>   04/29/02 03:51 PM
>
>   Please respond to
>
>   "Struts Users
>
>   Mailing List"
>
>
>
>
>
>
>
>
>
>
>
>
> Configure the web server to not recognize the .jsp mime type.  Then any
> link to a .jsp page will generate an "Error 404 Page Not Found". The
> servlet mappings should still work fine.
>
> That being said, I've found that whenever I make a decision like
> this based
> on a design preference, I almost always find some unusual case where it
> really makes sense to do things the way I've said shouldn't be done.
>
>
> FWIW -
> Kevin
>
>
>
>
>
>
>
> "Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM
>
> Please respond to "Struts Users Mailing List"
>   <[EMAIL PROTECTED]>
>
> To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
> Subject:  Design question
>
>
>
>
>
> In my opinion, most ( if not all ) links should be Action URIs.
> What I mean
> is, struts views should not post to urls which are JSP struts views.
> Rather, valid URLs that are posted to ( or even referenced in ) should
> always be controllers. For those who agree with this philosophy, can you
> give me some suggestions on how I can force this? One idea I've had is to
> place a customized on top of all JSP views which checks for a hidden
> request variable that only my controllers know about. So, if this request
> variable is not found than the view craps out. Any other ideas?
>
>
>
> ___
> Will Spies
> Towers Perrin
> Phone: (215)246-7145
> e-mail: [EMAIL PROTECTED] 
>
>
> --
> To unsubscribe, e-mail:   <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
>
> --
> -
> This e-mail message (including attachments, if any) is intended
> for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> --
> -
>
>
> --
> 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]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Design question

[James Mitchell]

Or

you could put your jsp's under the WEB-INF directory.

Search posts from a few weeks ago about this.
It's quite a lengthy and enlightening thread.


JM

> -Original Message-
> From: Will Spies/Towers Perrin [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 29, 2002 4:08 PM
> To: Struts Users Mailing List
> Subject: Re: Design question
>
>
>
>
> Good idea but the other problem is your web server doesn't mix with
> non-Struts applications. I was kinda hoping for a struts only solution.
> Thanks for the idea though!
>
>
> ___
> Will Spies
> Towers Perrin
> Phone: (215)246-7145
> e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>To:   "Struts
> Users Mailing List" <[EMAIL PROTECTED]>
>   Kevin.Bedell@sunl    cc:   (bcc:
> Will Spies/Towers Perrin)
>   ife.com  Subject:  Re:
> Design question
>
>
>   04/29/02 03:51 PM
>
>   Please respond to
>
>   "Struts Users
>
>   Mailing List"
>
>
>
>
>
>
>
>
>
>
>
>
> Configure the web server to not recognize the .jsp mime type.  Then any
> link to a .jsp page will generate an "Error 404 Page Not Found". The
> servlet mappings should still work fine.
>
> That being said, I've found that whenever I make a decision like
> this based
> on a design preference, I almost always find some unusual case where it
> really makes sense to do things the way I've said shouldn't be done.
>
>
> FWIW -
> Kevin
>
>
>
>
>
>
>
> "Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM
>
> Please respond to "Struts Users Mailing List"
>   <[EMAIL PROTECTED]>
>
> To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
> Subject:  Design question
>
>
>
>
>
> In my opinion, most ( if not all ) links should be Action URIs.
> What I mean
> is, struts views should not post to urls which are JSP struts views.
> Rather, valid URLs that are posted to ( or even referenced in ) should
> always be controllers. For those who agree with this philosophy, can you
> give me some suggestions on how I can force this? One idea I've had is to
> place a customized on top of all JSP views which checks for a hidden
> request variable that only my controllers know about. So, if this request
> variable is not found than the view craps out. Any other ideas?
>
>
>
> ___
> Will Spies
> Towers Perrin
> Phone: (215)246-7145
> e-mail: [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:   <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
>
> --
> -
> This e-mail message (including attachments, if any) is intended
> for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> --
> -
>
>
> --
> 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]>

Re: Design question

[Will Spies/Towers Perrin]

Good idea but the other problem is your web server doesn't mix with
non-Struts applications. I was kinda hoping for a struts only solution.
Thanks for the idea though!


___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


   

   

   To:   "Struts Users Mailing List" 
<[EMAIL PROTECTED]>  
  Kevin.Bedell@sunlcc:   (bcc: Will Spies/Towers 
Perrin)   
  ife.com      Subject:  Re: Design question   

   

  04/29/02 03:51 PM

  Please respond to

  "Struts Users

  Mailing List"

   

   








Configure the web server to not recognize the .jsp mime type.  Then any
link to a .jsp page will generate an "Error 404 Page Not Found". The
servlet mappings should still work fine.

That being said, I've found that whenever I make a decision like this based
on a design preference, I almost always find some unusual case where it
really makes sense to do things the way I've said shouldn't be done.


FWIW -
Kevin







"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Design question





In my opinion, most ( if not all ) links should be Action URIs. What I mean
is, struts views should not post to urls which are JSP struts views.
Rather, valid URLs that are posted to ( or even referenced in ) should
always be controllers. For those who agree with this philosophy, can you
give me some suggestions on how I can force this? One idea I've had is to
place a customized on top of all JSP views which checks for a hidden
request variable that only my controllers know about. So, if this request
variable is not found than the view craps out. Any other ideas?



___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---


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

Re: Design question

[Kevin . Bedell]

Configure the web server to not recognize the .jsp mime type.  Then any
link to a .jsp page will generate an "Error 404 Page Not Found". The
servlet mappings should still work fine.

That being said, I've found that whenever I make a decision like this based
on a design preference, I almost always find some unusual case where it
really makes sense to do things the way I've said shouldn't be done.


FWIW -
Kevin







"Will Spies/Towers Perrin" <[EMAIL PROTECTED]> on 04/29/2002 03:53:16 PM

Please respond to "Struts Users Mailing List"
  <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:  Design question





In my opinion, most ( if not all ) links should be Action URIs. What I mean
is, struts views should not post to urls which are JSP struts views.
Rather, valid URLs that are posted to ( or even referenced in ) should
always be controllers. For those who agree with this philosophy, can you
give me some suggestions on how I can force this? One idea I've had is to
place a customized on top of all JSP views which checks for a hidden
request variable that only my controllers know about. So, if this request
variable is not found than the view craps out. Any other ideas?



___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Design question

[Will Spies/Towers Perrin]

In my opinion, most ( if not all ) links should be Action URIs. What I mean
is, struts views should not post to urls which are JSP struts views.
Rather, valid URLs that are posted to ( or even referenced in ) should
always be controllers. For those who agree with this philosophy, can you
give me some suggestions on how I can force this? One idea I've had is to
place a customized on top of all JSP views which checks for a hidden
request variable that only my controllers know about. So, if this request
variable is not found than the view craps out. Any other ideas?



___
Will Spies
Towers Perrin
Phone: (215)246-7145
e-mail: [EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Presentation Layer Design Question

[@Basebeans.com]

Subject: Re: Presentation Layer Design Question
From: Vic Cekvenich <[EMAIL PROTECTED]>
 ===
Can't speak for Craig, but the Beans give me a way to isolate the DB 
layer. I use CachedRowSet to hold Result and have meta data at any time. 
It is one step and does not do mapping.
Since the DB layer is isolated, I can now have non web Apps use the 
beans, such as SOAP, etc.
I think beans are more traditional.
hth,
Vic

Adolfo Miguelez wrote:

> Hi All,
> 
> I am wondering about a design issue since I can not figure out why Craig 
> implemented in that way. Any light or opinion would be appreciated.
> 
> The point is that usually, AFAIK, results from database queries are 
> planned to be stored in ArrayLists of beans. This ArrayList of beans is 
> sent to the JSP which, in turns, by using  and 
>  tags can, for instance, work out a table.
> 
> After many headaches, we choosed to do the same by using an ArrayList of 
> HashMaps. HasMaps are filled with results from database with the same 
> info that beans. In our humble opinion, storing each database row in a 
> hashmap is easier vs storing in a specific bean. The points are:
> 
> - In both cases info about database headers is stored once for each row, 
> either get/set methods or key value of the hashmap, (no difference in 
> this matter),
> 
> - However a general ArrayList of HashMaps can be enought for holding all 
> the database result queries vs a specific bean for each query in the 
> Craig appproach. This would become the system much more mainteinable, 
> since we have a general holder for all the queries rather than a 
> specific one.
> 
> We developed a tag to inspect a value in the hashmap indexed by a key 
> and render such a value to the JSP, equivalent to how  
> inspects a get*** method of the bean to get the parameter.
> 
> The question is:
> 
> Is there any performance cost or design problem with this approach? Why 
> Craig did not take it?
> 
> Any comments in relation with this design are very welcome.
> 
> Regards,
> 
> adolfo
> 
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
> 
> 
> -- 
> 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]>

Presentation Layer Design Question

[Adolfo Miguelez]

Hi All,

I am wondering about a design issue since I can not figure out why Craig 
implemented in that way. Any light or opinion would be appreciated.

The point is that usually, AFAIK, results from database queries are planned 
to be stored in ArrayLists of beans. This ArrayList of beans is sent to the 
JSP which, in turns, by using  and  tags can, 
for instance, work out a table.

After many headaches, we choosed to do the same by using an ArrayList of 
HashMaps. HasMaps are filled with results from database with the same info 
that beans. In our humble opinion, storing each database row in a hashmap is 
easier vs storing in a specific bean. The points are:

- In both cases info about database headers is stored once for each row, 
either get/set methods or key value of the hashmap, (no difference in this 
matter),

- However a general ArrayList of HashMaps can be enought for holding all the 
database result queries vs a specific bean for each query in the Craig 
appproach. This would become the system much more mainteinable, since we 
have a general holder for all the queries rather than a specific one.

We developed a tag to inspect a value in the hashmap indexed by a key and 
render such a value to the JSP, equivalent to how  inspects a 
get*** method of the bean to get the parameter.

The question is:

Is there any performance cost or design problem with this approach? Why 
Craig did not take it?

Any comments in relation with this design are very welcome.

Regards,

adolfo

_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts design question re: form action

[Craig R. McClanahan]

On Sat, 13 Apr 2002, Wellie W. Chao wrote:

> Date: Sat, 13 Apr 2002 10:57:29 -0400
> From: Wellie W. Chao <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Struts design question re: form action
>
> I'm just curious about a design issue with Struts 1.1. The  tag
> has a "forward" attribute that lets you specify an entry from
> struts-config.xml as the destination of the link. That way you aren't tied
> to a particular action or a particular JSP/HTML page. Why isn't there a
> similar attribute for ? You have to directly specify the URI
> (using the "action" attribute) instead of being able to specify a forward
> mapping. It just seemed inconsistent to me.

A couple of reasons:

* The "action" parameter (which is used to specify the  you want)
  is already a logical indirection; the name of a bunch of business logic
  that you want to execute ("save customer") without knowing anything
  about the actual Action class that implements this logic.  It would be
  redundant to provide two different logical indirection schemes.

* Using a forward parameter instead of an action name would mean that the
  page has no way to infer what form bean to use, so you'd essentially
  have to give up all the fancy support provided for form beans.

Craig



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Struts design question re: form action

[Wellie W. Chao]

I'm just curious about a design issue with Struts 1.1. The  tag
has a "forward" attribute that lets you specify an entry from
struts-config.xml as the destination of the link. That way you aren't tied
to a particular action or a particular JSP/HTML page. Why isn't there a
similar attribute for ? You have to directly specify the URI
(using the "action" attribute) instead of being able to specify a forward
mapping. It just seemed inconsistent to me.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Nested Beans and Design Question

[@Basebeans.com]

Subject: Re: Nested Beans and Design Question
From: Vic Cekvenich <[EMAIL PROTECTED]>
 ===
#3.

I am not sure arrays are best (then again they might be).
Why just not retrieve a list of topics for the course, and click on a 
topic and retrieve a list of "assets", etc?

Vic

Matt Raible wrote:

> I have the following structure in my application
> 
> CourseForm
> -- TopicForm
> -- PageForm
> -- AssetForm
> 
> 
> Where a CourseForm has an ArrayList of TopicForms, TopicForm has an
> ArrayList of PageForms, etc.
> 
> I'm wondering what the suggested design is:
> 
> 
> Option 1:
> Populate everything on the first request - and keep it in the session.
> 
> Option 2: 
> Populate the CourseForm on the first request, and only populate the others
> with Id's, rather than entire forms.
> 
> Option 3:
> Only hold the courseId in the session, and look up information in each page
> as it's requested.
> 
> 
> There might be other options - feel free to add.
> 
> Basically, the first time a course is requested, I will have to look up the
> first topic, the first page, and the assets in that page.  So at first
> request, I will need all this "first" information.
> 
> Any tips or ideas are appreciated.
> 
> Thanks,
> 
> Matt
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Nested Beans and Design Question

[@Basebeans.com]

Subject: Nested Beans and Design Question
From: Matt Raible <[EMAIL PROTECTED]>
 ===
I have the following structure in my application

CourseForm
-- TopicForm
-- PageForm
-- AssetForm


Where a CourseForm has an ArrayList of TopicForms, TopicForm has an
ArrayList of PageForms, etc.

I'm wondering what the suggested design is:


Option 1:
Populate everything on the first request - and keep it in the session.

Option 2: 
Populate the CourseForm on the first request, and only populate the others
with Id's, rather than entire forms.

Option 3:
Only hold the courseId in the session, and look up information in each page
as it's requested.


There might be other options - feel free to add.

Basically, the first time a course is requested, I will have to look up the
first topic, the first page, and the assets in that page.  So at first
request, I will need all this "first" information.

Any tips or ideas are appreciated.

Thanks,

Matt


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Design question - action mappings

[jfc100]

Hi,

I am new to struts and am busy reading the various articles and 
tutorials and have a question regarding relationship between action 
mappings and request/session scopes.

Should an ActionMapping (i.e. a mapping defined in struts-config.xml) 
have a one-to-one relationship with a request or should it be reused 
many times within session scope? Or another way to ask the question 
would be within a storyboard, how many mapping objects should typically 
be designed to support that story.

Is there a design theory about how to do this? Do I have one action 
mapping for inserting a user's registration details and a seperate 
action mapping for editing them?

I am building a typical web app with membership-based users(with 
authentication and authorization) and a catalog/inventory browse/search 
facility as the key modules.

Thanks!
Joe



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts and Client Side JavaScript Design Question

[Ted Husted]

Managing JavaScripts in a Struts application is not much different than
managing it any Java application, so everything you've already read
should apply. 

One trick is to use the html:rewrite tag to resolve the address to
JavaScripts and other HTML assets, so that the path does not have to be
embedded in the markup. You can also use it to set the base hyperlink
for passing values to a script





and of course bean:write can help you buld runtime referneces 



I believe you can also use actions to create dynamic JavaScripts. So
instead of storing the *.js file on the server, you could have it
returned by an Action. 

Of course, JSP tags can also write dynamic scripts into the file, as the
Struts Validator does. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


[EMAIL PROTECTED] wrote:
> 
> Greetings.
>  We are in the early planning stages of a rather large Java/jsp application
> that if I have my way will use struts.  There will be a requirement for some
> "convenience"  features that will need to be in javascript.   I understand the
> pros's and con's of javascript and this will for the most part be for internal
> users.
> 
> Where possible, I look forward to using the validator  and  I like the way that
> it 'manages' the validation library.
> There will be many other functions such as auto population of controls from
> other events and some simple column math and so on.
> 
> In the past I read several articles on managing javascript from the server side.
> Other than storing all of it in a bunch of *.js files, can anyone share any
> experience they have had where they have been forced to maintain a large amount
> of javascript in a Struts application.
> 
> Thanks everyone
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Struts and Client Side JavaScript Design Question

[Jeff_Mychasiw]

Greetings.
 We are in the early planning stages of a rather large Java/jsp application
that if I have my way will use struts.  There will be a requirement for some
"convenience"  features that will need to be in javascript.   I understand the
pros's and con's of javascript and this will for the most part be for internal
users.

Where possible, I look forward to using the validator  and  I like the way that
it 'manages' the validation library.
There will be many other functions such as auto population of controls from
other events and some simple column math and so on.

In the past I read several articles on managing javascript from the server side.
Other than storing all of it in a bunch of *.js files, can anyone share any
experience they have had where they have been forced to maintain a large amount
of javascript in a Struts application.

Thanks everyone



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: design question

[Callas, Jeff P.]

Ted:
How can I get off the Struts Mailing List.
I've tried sending an eMail to:

To subscribe to the list, send a message to:
   <[EMAIL PROTECTED]>



-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 11:12 AM
To: Struts Users Mailing List
Subject: Re: design question


A third option people have mentioned is to serialize the form-bean as a
single hidden field. As part of validate, you can repopulate any null
fields. 

Never actually tried this one myself, but it seems clever. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


keithBacon wrote:
> 
> You have to keep the data in the session or write it to the database.
(Storing
> it on each form as hidden fields seems too fiddly to me).
> Unless you have huge volumes I actually prefer to save it on the database
&
> have a status field that indicates the data is incomplete.
> 
> --- Ronald Haring <[EMAIL PROTECTED]> wrote:
> > Ah yes,
> > that is a solution. But then you have to keep the general data in
session
> > indeed, which I never feel to comfortable about. But thx for the
pointer.
> >
> > Gr
> > Ronald
> >
> > > i see
> > > I am looking to build something similar and I am thinking of
> > > managing this
> > > through the action mappings.
> > > I am hoping to manage this as follows using the same action
> > > and keeping the
> > > form in the session.
> > > I plan to read up on building wizard type forms but from my
> > > small knowledge
> > > i think this wwould work
> > > e.g.
> > > 
> > >   parameter="PAGE1"
> > >   type=".mo..web.EditAction"
> > >   name="DatabaseTypeForm"
> > >   scope="session"
> > >   validate="false">
> > >   
> > > 
> > > 
> > > etc
> > > 
> > > 
> > > etc
> > > 
> > >
> > > etc
> > > 
> > >
> >
> >
> > Furore B.V.
> > Rijswijkstraat 175-8
> > Postbus 9204
> > 1006 AE Amsterdam
> > tel. (020) 346 71 71
> > fax. (020) 346 71 77
> >
> >

> > ---
> > The information transmitted is intended only for the person
> > or entity to which it is addressed and may contain confidential
> > and/or privileged material. Any review, retransmission,
> > dissemination or other use of, or taking of any action in
> > reliance upon, this information by persons or entities other
> > than the intended recipient is prohibited. If you received
> > this in error, please contact the sender and delete the material
> > from any computer
> >

> > ---
> >
> >
> 
> =
> ~~
> Search the archive:-
> http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> ~~
> Keith Bacon - Looking for struts work - South-East UK.
> phone UK 07960 011275
> 
> __
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/
> 
> --
> 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]>

RE: design question

[Ronald Haring]

this looks very nice indeed. I will look into this some more. Thx Ted

Gr
Ronald 

> At this point, I rarely write custom Actions any more. Now I 
> try to use
> a framework action to handle all the usual action-stuff, and 
> pass it the
> name of a business bean to invoke as part of the 
> ActionMapping. At this
> point, I'm creating moderately complex application using only 
> the stock
> actions in the scaffold package. Lots and lots of business beans, but
> very action classes. 
> 
> http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/
> src/framework/main/org/apache/scaffold/http/
> 
> What I'm thinking about now is extending ActionMapping so that it has
> the same type of functionality embedded in the DispatchAction. To wit,
> let you specify an object to instantiate and a method to call from the
> ActionMapping. There could actually be a couple of different method
> signatures to call, maybe a perform, an execute, and then an 
> invoke that
> just took a single object (the ActionForm), but have them 
> each return a
> collection. There could also be an attribute to give whatever they
> return a name, and pop it into a context. 
> 
> I think we can really dispense with most actions almost 
> completely, and
> configure most everything from the Struts config, as Craig 
> envisioned in
> his workflow proposal. Most of what the Actions do is very 
> predictible,
> it's just the wee-bit of business logic in the middle that makes one
> different from the other.


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

Re: design question

[Ted Husted]

At this point, I rarely write custom Actions any more. Now I try to use
a framework action to handle all the usual action-stuff, and pass it the
name of a business bean to invoke as part of the ActionMapping. At this
point, I'm creating moderately complex application using only the stock
actions in the scaffold package. Lots and lots of business beans, but
very action classes. 

http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/framework/main/org/apache/scaffold/http/

What I'm thinking about now is extending ActionMapping so that it has
the same type of functionality embedded in the DispatchAction. To wit,
let you specify an object to instantiate and a method to call from the
ActionMapping. There could actually be a couple of different method
signatures to call, maybe a perform, an execute, and then an invoke that
just took a single object (the ActionForm), but have them each return a
collection. There could also be an attribute to give whatever they
return a name, and pop it into a context. 

I think we can really dispense with most actions almost completely, and
configure most everything from the Struts config, as Craig envisioned in
his workflow proposal. Most of what the Actions do is very predictible,
it's just the wee-bit of business logic in the middle that makes one
different from the other.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Ronald Haring wrote:
> 
> Hi all,
> 
> I've studied the design paper that Ted has put up at his site
> (http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear
> explanation Ted, it only left me with one question. In your paper you state
> that every form should have its own action. However for my last project (and
> my first struts project) I used the same action for most of the forms.
> 
> This action would then decide based upon a navigate field in the form :
> - which formBean to create and populate
> - which mapping to return
> 
> based on a large if (navigation.equals("")) tree.
> 
> I submitted always to the same form, so that this ControllerAction could
> perform some default behavious I liked to execute (e.g. dynamic change of
> language, default SQLException handling) and that all the navigation was in
> the same class.
> Somehow I have the feeling that this is not the way to go.
> 
> However on the detail screens there are links to other detail screens. These
> are simple links like 
> ...  etc etc. (where
> goSubmit is a javascript function that will fill the navigate field with the
> given value and then submit the form). If I want a action for every form how
> should I set this so that showFirstDetailsScreen will go to the right
> action, without using multiple forms (since this really screws up the html
> lay-out)
> 
> Gr
> Ronald
> 
> Furore B.V.
> Rijswijkstraat 175-8
> Postbus 9204
> 1006 AE Amsterdam
> tel. (020) 346 71 71
> fax. (020) 346 71 77
> 
> 
> ---
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material
> from any computer
> 
> ---

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: design question

[Ted Husted]

A third option people have mentioned is to serialize the form-bean as a
single hidden field. As part of validate, you can repopulate any null
fields. 

Never actually tried this one myself, but it seems clever. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


keithBacon wrote:
> 
> You have to keep the data in the session or write it to the database. (Storing
> it on each form as hidden fields seems too fiddly to me).
> Unless you have huge volumes I actually prefer to save it on the database &
> have a status field that indicates the data is incomplete.
> 
> --- Ronald Haring <[EMAIL PROTECTED]> wrote:
> > Ah yes,
> > that is a solution. But then you have to keep the general data in session
> > indeed, which I never feel to comfortable about. But thx for the pointer.
> >
> > Gr
> > Ronald
> >
> > > i see
> > > I am looking to build something similar and I am thinking of
> > > managing this
> > > through the action mappings.
> > > I am hoping to manage this as follows using the same action
> > > and keeping the
> > > form in the session.
> > > I plan to read up on building wizard type forms but from my
> > > small knowledge
> > > i think this wwould work
> > > e.g.
> > > 
> > >   parameter="PAGE1"
> > >   type=".mo..web.EditAction"
> > >   name="DatabaseTypeForm"
> > >   scope="session"
> > >   validate="false">
> > >   
> > > 
> > > 
> > > etc
> > > 
> > > 
> > > etc
> > > 
> > >
> > > etc
> > > 
> > >
> >
> >
> > Furore B.V.
> > Rijswijkstraat 175-8
> > Postbus 9204
> > 1006 AE Amsterdam
> > tel. (020) 346 71 71
> > fax. (020) 346 71 77
> >
> > 
> > ---
> > The information transmitted is intended only for the person
> > or entity to which it is addressed and may contain confidential
> > and/or privileged material. Any review, retransmission,
> > dissemination or other use of, or taking of any action in
> > reliance upon, this information by persons or entities other
> > than the intended recipient is prohibited. If you received
> > this in error, please contact the sender and delete the material
> > from any computer
> > 
> > ---
> >
> >
> 
> =
> ~~
> Search the archive:-
> http://www.mail-archive.com/struts-user%40jakarta.apache.org/
> ~~
> Keith Bacon - Looking for struts work - South-East UK.
> phone UK 07960 011275
> 
> __
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: design question

[Ronald Haring]

> You have to keep the data in the session or write it to the 
> database. (Storing
> it on each form as hidden fields seems too fiddly to me).
> Unless you have huge volumes I actually prefer to save it on 
> the database &
> have a status field that indicates the data is incomplete.

that is true for data entry screens. Not for various display screens where
you only need an identifier to retrieve your information from a database.

For data entry screens I think I will have to rely on sessions, since I like
my data in the database to be complete otherwise you should have a worker
thread to check your database for incomplete fields and destroy these
incomplete records after a number of time/days/weeks.

Gr
Ronald


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

RE: design question

[Ronald Haring]

I have one big problem and one minor problem with keeping information in
sessions
- it takes memory, and you have no way of telling when this will released
(sure if session timeouts, then you might suspect that it will be cleaned
any time soon, but its always up to the gc to do that, so never sure)
- when using load balancing you have to use sticky redirection to the server
maintaining the session object for this user (but this is not very important
yet and I know you will have to do that with only a sessionid key in the
client object as well)



Gr
Ronald 

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 05, 2002 3:47 PM
> To: Struts Users Mailing List
> Subject: Re: design question
> 
> 
> There's really no reason not to keep the data in the session. 
>  The session
> is server-side and is not transmitted to the client, so it's 
> secure.  I
> can't think of any other reason you would be uncomfortable 
> with using the
> session, but if you have a different concern please feel free 
> to voice it.
> 
> HTH,
> 
> Eddie
> 
> - Original Message -
> From: "Ronald Haring" <[EMAIL PROTECTED]>
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 05, 2002 7:07 AM
> Subject: RE: design question
> 
> 
> > Ah yes,
> > that is a solution. But then you have to keep the general 
> data in session
> > indeed, which I never feel to comfortable about. But thx 
> for the pointer.
> >
> > Gr
> > Ronald
> >
> > > i see
> > > I am looking to build something similar and I am thinking of
> > > managing this
> > > through the action mappings.
> > > I am hoping to manage this as follows using the same action
> > > and keeping the
> > > form in the session.
> > > I plan to read up on building wizard type forms but from my
> > > small knowledge
> > > i think this wwould work
> > > e.g.
> > > 
> > >   parameter="PAGE1"
> > >   type=".mo..web.EditAction"
> > >   name="DatabaseTypeForm"
> > >   scope="session"
> > >   validate="false">
> > >   
> > > 
> > > 
> > > etc
> > > 
> > > 
> > > etc
> > > 
> > >
> > > etc
> > > 
> > >
> >
> >
> > Furore B.V.
> > Rijswijkstraat 175-8
> > Postbus 9204
> > 1006 AE Amsterdam
> > tel. (020) 346 71 71
> > fax. (020) 346 71 77
> >
> > 
> --
> 
> --
> > ---
> > The information transmitted is intended only for the person
> > or entity to which it is addressed and may contain confidential
> > and/or privileged material. Any review, retransmission,
> > dissemination or other use of, or taking of any action in
> > reliance upon, this information by persons or entities other
> > than the intended recipient is prohibited. If you received
> > this in error, please contact the sender and delete the material
> > from any computer
> > 
> --
> 
> --
> > ---
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

Re: design question

[Eddie Bush]

There's really no reason not to keep the data in the session.  The session
is server-side and is not transmitted to the client, so it's secure.  I
can't think of any other reason you would be uncomfortable with using the
session, but if you have a different concern please feel free to voice it.

HTH,

Eddie

- Original Message -
From: "Ronald Haring" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Tuesday, March 05, 2002 7:07 AM
Subject: RE: design question


> Ah yes,
> that is a solution. But then you have to keep the general data in session
> indeed, which I never feel to comfortable about. But thx for the pointer.
>
> Gr
> Ronald
>
> > i see
> > I am looking to build something similar and I am thinking of
> > managing this
> > through the action mappings.
> > I am hoping to manage this as follows using the same action
> > and keeping the
> > form in the session.
> > I plan to read up on building wizard type forms but from my
> > small knowledge
> > i think this wwould work
> > e.g.
> > 
> >   parameter="PAGE1"
> >   type=".mo..web.EditAction"
> >   name="DatabaseTypeForm"
> >   scope="session"
> >   validate="false">
> >   
> > 
> > 
> > etc
> > 
> > 
> > etc
> > 
> >
> > etc
> > 
> >
>
>
> Furore B.V.
> Rijswijkstraat 175-8
> Postbus 9204
> 1006 AE Amsterdam
> tel. (020) 346 71 71
> fax. (020) 346 71 77
>
> --
--
> ---
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material
> from any computer
> --
--
> ---
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: design question

[keithBacon]

You have to keep the data in the session or write it to the database. (Storing
it on each form as hidden fields seems too fiddly to me).
Unless you have huge volumes I actually prefer to save it on the database &
have a status field that indicates the data is incomplete.

--- Ronald Haring <[EMAIL PROTECTED]> wrote:
> Ah yes, 
> that is a solution. But then you have to keep the general data in session
> indeed, which I never feel to comfortable about. But thx for the pointer.
> 
> Gr
> Ronald
> 
> > i see
> > I am looking to build something similar and I am thinking of 
> > managing this
> > through the action mappings.
> > I am hoping to manage this as follows using the same action 
> > and keeping the
> > form in the session. 
> > I plan to read up on building wizard type forms but from my 
> > small knowledge
> > i think this wwould work
> > e.g.
> > 
> >   parameter="PAGE1"
> >   type=".mo..web.EditAction"
> >   name="DatabaseTypeForm"
> >   scope="session"
> >   validate="false">
> >   
> > 
> > 
> > etc
> > 
> > 
> > etc
> > 
> >
> > etc
> > 
> > 
> 
> 
> Furore B.V.
> Rijswijkstraat 175-8
> Postbus 9204
> 1006 AE Amsterdam
> tel. (020) 346 71 71
> fax. (020) 346 71 77
> 
> 
> ---
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material
> from any computer
> 
> ---
> 
> 


=
~~
Search the archive:-
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
~~
Keith Bacon - Looking for struts work - South-East UK.
phone UK 07960 011275

__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: design question

[Ronald Haring]

Ah yes, 
that is a solution. But then you have to keep the general data in session
indeed, which I never feel to comfortable about. But thx for the pointer.

Gr
Ronald

> i see
> I am looking to build something similar and I am thinking of 
> managing this
> through the action mappings.
> I am hoping to manage this as follows using the same action 
> and keeping the
> form in the session. 
> I plan to read up on building wizard type forms but from my 
> small knowledge
> i think this wwould work
> e.g.
> 
>   parameter="PAGE1"
>   type=".mo..web.EditAction"
>   name="DatabaseTypeForm"
>   scope="session"
>   validate="false">
>   
> 
> 
>   etc
> 
> 
>   etc
> 
>
>   etc
> 
> 


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

RE: design question

[Lister, Tom (ANTS)]

i see
I am looking to build something similar and I am thinking of managing this
through the action mappings.
I am hoping to manage this as follows using the same action and keeping the
form in the session. 
I plan to read up on building wizard type forms but from my small knowledge
i think this wwould work
e.g.

  parameter="PAGE1"
  type=".mo..web.EditAction"
  name="DatabaseTypeForm"
  scope="session"
  validate="false">
  


etc


etc

   
etc


-Original Message-
From: Ronald Haring [mailto:[EMAIL PROTECTED]]
Sent: 05 March 2002 12:51
To: 'Struts Users Mailing List'
Subject: RE: design question


> If key tasks needs to be completed in each Action's perform() 
> method, a good
> approach is to create a new abstract methods for your 
> subclasses to use in
> lieu of perform(). The base Action class does its business, 
> and if all is
> well, then returns the result of the new method. This allows 
> you to change
> the signature of your new method, if there is ever any reason 
> for that, and
> provides a cleaner flow. 
> 
> public ActionForward perform(ActionMapping mapping,
>  ActionForm form,
>  HttpServletRequest request,
>  HttpServletResponse response)
> throws IOException, ServletException { 
> 
> // Application specific behaviour
> // if everything is kosher call subclass 
> 
> return ( performAction(mapping,form,request,response, 
> myParameter )

yes indeed, this will be cleaner and better then my solution. However I am
still stuck with the submit to different actions aspect, for which I used
the general controller.

(Quoting myself, finally I got quoted ;)

> However on the detail screens there are links to other detail 
> screens. These
> are simple links like  href=javascipt:goSubmit('showFirstDetailsScreen')>
> ...  
> etc etc. (where
> goSubmit is a javascript function that will fill the navigate 
> field with the
> given value and then submit the form). If I want a action for 
> every form how
> should I set this so that showFirstDetailsScreen will go to the right
> action, without using multiple forms (since this really 
> screws up the html
> lay-out)

Gr
Ronald


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---



***
This email message contains confidential information for the above addressee only.  If 
you are not the intended addressee you must not disclose or use the information in any 
manner whatsoever.

Any opinion or views contained in this email message are those of the sender, do not 
represent those of the Company in any way and reliance should not be placed upon its 
contents.

Unless otherwise stated this email message is not intended to be contractually 
binding.  Where an Agreement exists between our respective companies and there is 
conflict between the contents of this email message and the Agreement then the terms 
of that Agreement shall prevail.

Abbey National Treasury Services plc. Registered in England. Registered Office:  Abbey 
House, Baker Street, London NW1 6XL.  Company Registration No: 2338548.  Regulated by 
the FSA
***


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: design question

[Ronald Haring]

> If key tasks needs to be completed in each Action's perform() 
> method, a good
> approach is to create a new abstract methods for your 
> subclasses to use in
> lieu of perform(). The base Action class does its business, 
> and if all is
> well, then returns the result of the new method. This allows 
> you to change
> the signature of your new method, if there is ever any reason 
> for that, and
> provides a cleaner flow. 
> 
> public ActionForward perform(ActionMapping mapping,
>  ActionForm form,
>  HttpServletRequest request,
>  HttpServletResponse response)
> throws IOException, ServletException { 
> 
> // Application specific behaviour
> // if everything is kosher call subclass 
> 
> return ( performAction(mapping,form,request,response, 
> myParameter )

yes indeed, this will be cleaner and better then my solution. However I am
still stuck with the submit to different actions aspect, for which I used
the general controller.

(Quoting myself, finally I got quoted ;)

> However on the detail screens there are links to other detail 
> screens. These
> are simple links like  href=javascipt:goSubmit('showFirstDetailsScreen')>
> ...  
> etc etc. (where
> goSubmit is a javascript function that will fill the navigate 
> field with the
> given value and then submit the form). If I want a action for 
> every form how
> should I set this so that showFirstDetailsScreen will go to the right
> action, without using multiple forms (since this really 
> screws up the html
> lay-out)

Gr
Ronald


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

RE: design question

[Lister, Tom (ANTS)]

I'm sure I've seen some notes on this in the Struts resources
to get common behaviour
Create your own action class that extends the struts Actions to hold common
function calls
Have your specific actions extend this default Action
You can further subclass the default action e.g. we have a subclass
DefaulCRUDAction with specific behaviours

Some where I've seen a variation on this where the base class action perform
calls a different method on each specific action
Ah found it see
Ted Husted's Struts Catalog
Quote ."
Use a Base Action for your application
Often, the Actions in your application will need to perform some basic
tasks. To ensure these tasks are implement consistently, create a base
Action for the others in your application to subclass.  

If key tasks needs to be completed in each Action's perform() method, a good
approach is to create a new abstract methods for your subclasses to use in
lieu of perform(). The base Action class does its business, and if all is
well, then returns the result of the new method. This allows you to change
the signature of your new method, if there is ever any reason for that, and
provides a cleaner flow. 

public ActionForward perform(ActionMapping mapping,
 ActionForm form,
 HttpServletRequest request,
 HttpServletResponse response)
throws IOException, ServletException { 

// Application specific behaviour
// if everything is kosher call subclass 

return ( performAction(mapping,form,request,response, myParameter )
)
   } 

   where performAction is an abstract method of the base class. 

..."
-Original Message-
From: Ronald Haring [mailto:[EMAIL PROTECTED]]
Sent: 05 March 2002 12:15
To: '[EMAIL PROTECTED]'
Subject: design question


Hi all,

I've studied the design paper that Ted has put up at his site
(http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear
explanation Ted, it only left me with one question. In your paper you state
that every form should have its own action. However for my last project (and
my first struts project) I used the same action for most of the forms.

This action would then decide based upon a navigate field in the form :
- which formBean to create and populate
- which mapping to return

based on a large if (navigation.equals("")) tree.

I submitted always to the same form, so that this ControllerAction could
perform some default behavious I liked to execute (e.g. dynamic change of
language, default SQLException handling) and that all the navigation was in
the same class. 
Somehow I have the feeling that this is not the way to go.

However on the detail screens there are links to other detail screens. These
are simple links like 
...  etc etc. (where
goSubmit is a javascript function that will fill the navigate field with the
given value and then submit the form). If I want a action for every form how
should I set this so that showFirstDetailsScreen will go to the right
action, without using multiple forms (since this really screws up the html
lay-out)


Gr
Ronald 


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---



***
This email message contains confidential information for the above addressee only.  If 
you are not the intended addressee you must not disclose or use the information in any 
manner whatsoever.

Any opinion or views contained in this email message are those of the sender, do not 
represent those of the Company in any way and reliance should not be placed upon its 
contents.

Unless otherwise stated this email message is not intended to be contractually 
binding.  Where an Agreement exists between our respective companies and there is 
conflict between the contents of this email message and the Agreement then the terms 
of that Agreement shall prevail.

Abbey National Treasury Services plc. Registered in England. Registered Office:  Abbey 
House, Baker Street, London NW1 6XL.  Company Registration No: 2338548.  Regulated by 
the FSA
***


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

design question

[Ronald Haring]

Hi all,

I've studied the design paper that Ted has put up at his site
(http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear
explanation Ted, it only left me with one question. In your paper you state
that every form should have its own action. However for my last project (and
my first struts project) I used the same action for most of the forms.

This action would then decide based upon a navigate field in the form :
- which formBean to create and populate
- which mapping to return

based on a large if (navigation.equals("")) tree.

I submitted always to the same form, so that this ControllerAction could
perform some default behavious I liked to execute (e.g. dynamic change of
language, default SQLException handling) and that all the navigation was in
the same class. 
Somehow I have the feeling that this is not the way to go.

However on the detail screens there are links to other detail screens. These
are simple links like 
...  etc etc. (where
goSubmit is a javascript function that will fill the navigate field with the
given value and then submit the form). If I want a action for every form how
should I set this so that showFirstDetailsScreen will go to the right
action, without using multiple forms (since this really screws up the html
lay-out)


Gr
Ronald 


Furore B.V.
Rijswijkstraat 175-8
Postbus 9204
1006 AE Amsterdam
tel. (020) 346 71 71
fax. (020) 346 71 77


---
The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material
from any computer

---

Re: Struts design question about maintenance screens

[Ted Husted]

The standard DispatchAction can be a handy way to keep various tasks
together in the same Action, where they can share code, but without
getting into kludgy performs. Dispatch lets you have a separate perform
for each task, but all in the same Action, where they can be easier to
maintain. 

http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/actions/DispatchAction.html

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


[EMAIL PROTECTED] wrote:
> 
> Hi Folks:
> 
> thanks to your help, you indicated that the Action should preload form
> values on a maintenance form.   This works great.
> 
> I have an Action object that allows maintenance on a table (call it table
> A).   This action object handles "preloading of data"
> as well as the actual "updating of data" (Add/Edit/View).
> 
> Another question I have:
> - The action object gets kind of "kludgey" in how I have to keep track of
> "whether I am preloading data (called from a html:link)" or whether I am
> "Applying" the data (called from the form Submit).
> Is it "overkill" if I create 2 different actions (1 action to preload the
> data and another to "update" the data)?I think by doing it this way, it
> may be easier for me to incorporate the "sensitive form resubmit"
> prevention by using tokens.
> 
> Any suggestions are much appreciated.
> 
> thanks,
> Theron
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts design question about maintenance screens

[Jakkampudi, ChandraseKhar]

Another drawback of Option 1 is that if your jsp's change frequently (adding
fields in the form, different formatting etc.) having two jsp's requires you
to update two files. This is not a problem in itself but it might make for
more difficult maintenance because you might make changes on one jsp but
forget the other.
Just another thing to consider when you make your design choice.

Option 3 sounds attractive. Thanks for the idea, Emaho.

JC

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 12:09 PM
To: Struts Users Mailing List
Cc: [EMAIL PROTECTED]
Subject: RE: Struts design question about maintenance screens



Wow!
Great reply.   I am saving this one.

thanks,
Theron



 

"Emaho, Ghoot"

  
ICS.co.uk>   cc:

 Subject: RE: Struts design
question about maintenance screens   
02/21/02 09:51 AM

Please respond to

Struts Users

Mailing List

 

 




There are a number of ways to achieve this, and again (!) it's about
choice, although I must say this can be confusing for newbie  (and
experienced!) struts users.

1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.

Option 3 is basically an added method to the ActionForm class that allows
the Action to determine if 'pre' or 'post' processing the form, without the
need for an 'action' parameter. Consider the following in the Action class,
where 'sf' refers to the instance of the form:

// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return
mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);

// getting this far indicates post-processing...

/**
 * Determines if pre or post processing the form.
 * Criteria being null indicates pre-processing.
 *
 * @return true if pre-processing the form
 */
public boolean isVirgin () {
return ( (criteria == null) );
}

The 'isVirgin' method returns true if 'pre' processing the form, and false
if 'post' processing.

Option 1 gives good seperation, but can lead to an unneccesary
proliferation of Action classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post
processing in the one Action - however, this doesn't extend as far as
seperate actions and action parameters when you need to do more than just
pre and post processing.

In our applications we have used all 3 at various times. We tend to use
option 3 when we just need the split between pre and post processing, eg a
Search or Login action. In more complex sceanrio's we tend to use option 1
or 2.

Try to determine which best fits your scenario. Depending on your context,
one solution may be better than the other, but this will not be true across
the board for all scenarios. Think through your real needs before choosing
the solution.

With regards to your exact scenario, we developed option 3 as a solution to
this very situation, so I would suggest option 3 might be best suited,
although you will ultimately have to decide ! Having developed option 3 and
implemented it, we have found it to be the most effective way of getting
around this. As I previously stated, option 1 and 2 come into their own in
other situations.

Hope this helps - if you need any more detail let me know,

Ghoot


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 February 2002 17:10
> To: Struts Users Mailing List
> Subject: Struts design question about maintenance screens
>
>
>
> Hi Folks:
>
> thanks to your help, you indicated that the Action should preload form
> values on a maintenance form.   This works great.
>
> I have an Action object that allows maintenance on a table
> (call it table
> A).   This action object handles "preloading of data"
> as well as the actual "updating of data" (Add/Edit/View).
>
> Another question I have:
> - The action object gets kind of "kludgey" in how I have to
> keep track of
> "whether I am preloading data (called from a html:link)" or
> whether I am
> "Applying" the data (called from the form Submit).
> Is it "overkill" if I create 2 different actions (1 action to
> preload the
> data and another to "update" the data)?I think by doing
> it this way, it
> may be easier for me to incorporate the "sensitive form resubmit"

RE: Struts design question about maintenance screens

[theron . kousek]

Wow!
Great reply.   I am saving this one.

thanks,
Theron



   
  
"Emaho, Ghoot" 
  
  
ICS.co.uk>   cc:   
  
 Subject:     RE: Struts design question 
about maintenance screens   
02/21/02 09:51 AM  
  
Please respond to  
  
Struts Users   
  
Mailing List   
  
   
  
   
  



There are a number of ways to achieve this, and again (!) it's about
choice, although I must say this can be confusing for newbie  (and
experienced!) struts users.

1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.

Option 3 is basically an added method to the ActionForm class that allows
the Action to determine if 'pre' or 'post' processing the form, without the
need for an 'action' parameter. Consider the following in the Action class,
where 'sf' refers to the instance of the form:

// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return
mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);

// getting this far indicates post-processing...

/**
 * Determines if pre or post processing the form.
 * Criteria being null indicates pre-processing.
 *
 * @return true if pre-processing the form
 */
public boolean isVirgin () {
return ( (criteria == null) );
}

The 'isVirgin' method returns true if 'pre' processing the form, and false
if 'post' processing.

Option 1 gives good seperation, but can lead to an unneccesary
proliferation of Action classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post
processing in the one Action - however, this doesn't extend as far as
seperate actions and action parameters when you need to do more than just
pre and post processing.

In our applications we have used all 3 at various times. We tend to use
option 3 when we just need the split between pre and post processing, eg a
Search or Login action. In more complex sceanrio's we tend to use option 1
or 2.

Try to determine which best fits your scenario. Depending on your context,
one solution may be better than the other, but this will not be true across
the board for all scenarios. Think through your real needs before choosing
the solution.

With regards to your exact scenario, we developed option 3 as a solution to
this very situation, so I would suggest option 3 might be best suited,
although you will ultimately have to decide ! Having developed option 3 and
implemented it, we have found it to be the most effective way of getting
around this. As I previously stated, option 1 and 2 come into their own in
other situations.

Hope this helps - if you need any more detail let me know,

Ghoot


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 February 2002 17:10
> To: Struts Users Mailing List
> Subject: Struts design question about maintenance screens
>
>
>
> Hi Folks:
>
> thanks to your help, you indicated that the Action should preload form
> values on a maintenance form.   This works great.
>
> I have an Action object that allows maintenance on a table
> (call it table
> A).   This action object handles "preloading of data"
> as well as the actual "updating of data" (Add/Edit/View).
>
> Another question I have:
> - The action object gets kind of "kludgey" in how I have to
> keep track of
> "whether I am preloading data (called from a html:link)" or
> whether I am
> "Applying" the data (called from the form Submit).
> Is it "overkill" if I create 2 different actions (1 action to
> preload the
> data and another to "update" the data)?I think by d

RE: Struts design question about maintenance screens

[Emaho, Ghoot]

There are a number of ways to achieve this, and again (!) it's about choice, although 
I must say this can be confusing for newbie  (and experienced!) struts users.

1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.

Option 3 is basically an added method to the ActionForm class that allows the Action 
to determine if 'pre' or 'post' processing the form, without the need for an 'action' 
parameter. Consider the following in the Action class, where 'sf' refers to the 
instance of the form:

// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);

// getting this far indicates post-processing...

/**
 * Determines if pre or post processing the form.
 * Criteria being null indicates pre-processing.
 *
 * @return true if pre-processing the form  
 */
public boolean isVirgin () {
return ( (criteria == null) );
}

The 'isVirgin' method returns true if 'pre' processing the form, and false if 'post' 
processing.

Option 1 gives good seperation, but can lead to an unneccesary proliferation of Action 
classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post processing in the 
one Action - however, this doesn't extend as far as seperate actions and action 
parameters when you need to do more than just pre and post processing.

In our applications we have used all 3 at various times. We tend to use option 3 when 
we just need the split between pre and post processing, eg a Search or Login action. 
In more complex sceanrio's we tend to use option 1 or 2.

Try to determine which best fits your scenario. Depending on your context, one 
solution may be better than the other, but this will not be true across the board for 
all scenarios. Think through your real needs before choosing the solution.

With regards to your exact scenario, we developed option 3 as a solution to this very 
situation, so I would suggest option 3 might be best suited, although you will 
ultimately have to decide ! Having developed option 3 and implemented it, we have 
found it to be the most effective way of getting around this. As I previously stated, 
option 1 and 2 come into their own in other situations.

Hope this helps - if you need any more detail let me know,

Ghoot


> -Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 21 February 2002 17:10
> To: Struts Users Mailing List
> Subject: Struts design question about maintenance screens
> 
> 
> 
> Hi Folks:
> 
> thanks to your help, you indicated that the Action should preload form
> values on a maintenance form.   This works great.
> 
> I have an Action object that allows maintenance on a table 
> (call it table
> A).   This action object handles "preloading of data"
> as well as the actual "updating of data" (Add/Edit/View).
> 
> Another question I have:
> - The action object gets kind of "kludgey" in how I have to 
> keep track of
> "whether I am preloading data (called from a html:link)" or 
> whether I am
> "Applying" the data (called from the form Submit).
> Is it "overkill" if I create 2 different actions (1 action to 
> preload the
> data and another to "update" the data)?I think by doing 
> it this way, it
> may be easier for me to incorporate the "sensitive form resubmit"
> prevention by using tokens.
> 
> Any suggestions are much appreciated.
> 
> thanks,
> Theron
> 
> 
> --
> 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]>

RE: Struts design question about maintenance screens

[theron . kousek]

thanks Simon:

With all do respect to the other method (ie, parameters), I tend to favor
your approach.I have just completed a maintenance screen by having a
combined action and I don't like the if-else's and the action file is huge.
By splitting it, I can re-use the LoadFormAction in other areas as well as
the SaveAction and not have both operations (load and save) tightly coupled
as I don't feel they should be tightly coupled.The only drawback I see
with this favorable approach is more source files but these source files
will be smaller and more maintanable/straight-forward I believe.

Before I went with this approach, I just wanted to hear how others felt
about this approach.

thanks for your input.

Theron




   

"Chappell, Simon P"

  
dsend.com> cc: 

   Subject:     RE: Struts design question 
about maintenance screens   
02/21/02 09:38 AM  

Please respond to  

Struts Users   

Mailing List   

   

   




In reference to having two actions (create and update) instead of one
combined action, this is exactly what I have done. While the struts-example
uses a parameter, I personally prefer not to take that route.

I have simplified my code/JSPs by having each do only one thing (good OO)
at the slight expense of increasing the number of Java classes and JSPs.

Using 2 JSP instead of 1 might seem like duplication, but there isn't that
much and each JSP is much easier to read/maintain than the single JSP that
is trying to pretend it's two. The extra action classes are also not a big
deal as I move more and more logic out of the action classes themselves.

Just my thoughts.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 21, 2002 11:10 AM
>To: Struts Users Mailing List
>Subject: Struts design question about maintenance screens
>
>
>
>Hi Folks:
>
>thanks to your help, you indicated that the Action should preload form
>values on a maintenance form.   This works great.
>
>I have an Action object that allows maintenance on a table
>(call it table
>A).   This action object handles "preloading of data"
>as well as the actual "updating of data" (Add/Edit/View).
>
>Another question I have:
>- The action object gets kind of "kludgey" in how I have to
>keep track of
>"whether I am preloading data (called from a html:link)" or
>whether I am
>"Applying" the data (called from the form Submit).
>Is it "overkill" if I create 2 different actions (1 action to
>preload the
>data and another to "update" the data)?I think by doing it
>this way, it
>may be easier for me to incorporate the "sensitive form resubmit"
>prevention by using tokens.
>
>Any suggestions are much appreciated.
>
>thanks,
>Theron
>
>
>--
>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]>

RE: Struts design question about maintenance screens

[Chappell, Simon P]

In reference to having two actions (create and update) instead of one combined action, 
this is exactly what I have done. While the struts-example uses a parameter, I 
personally prefer not to take that route.

I have simplified my code/JSPs by having each do only one thing (good OO) at the 
slight expense of increasing the number of Java classes and JSPs.

Using 2 JSP instead of 1 might seem like duplication, but there isn't that much and 
each JSP is much easier to read/maintain than the single JSP that is trying to pretend 
it's two. The extra action classes are also not a big deal as I move more and more 
logic out of the action classes themselves.

Just my thoughts.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 21, 2002 11:10 AM
>To: Struts Users Mailing List
>Subject: Struts design question about maintenance screens
>
>
>
>Hi Folks:
>
>thanks to your help, you indicated that the Action should preload form
>values on a maintenance form.   This works great.
>
>I have an Action object that allows maintenance on a table 
>(call it table
>A).   This action object handles "preloading of data"
>as well as the actual "updating of data" (Add/Edit/View).
>
>Another question I have:
>- The action object gets kind of "kludgey" in how I have to 
>keep track of
>"whether I am preloading data (called from a html:link)" or 
>whether I am
>"Applying" the data (called from the form Submit).
>Is it "overkill" if I create 2 different actions (1 action to 
>preload the
>data and another to "update" the data)?I think by doing it 
>this way, it
>may be easier for me to incorporate the "sensitive form resubmit"
>prevention by using tokens.
>
>Any suggestions are much appreciated.
>
>thanks,
>Theron
>
>
>--
>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]>

RE: Struts design question about maintenance screens

[Jakkampudi, ChandraseKhar]

You dont need two actions. You can use an 'action' parameter to decide which
action you are performing. 
On your html:link add a parameter action="view" 
and on the submit action="add" or action="edit" depending on  what you are
doing.
In your action, you can have if statements that perform different functions
base on what you are doing.

There is an example in the struts docs that explains this. (Cant find it
now. you have to search for it)

-JC

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 11:10 AM
To: Struts Users Mailing List
Subject: Struts design question about maintenance screens



Hi Folks:

thanks to your help, you indicated that the Action should preload form
values on a maintenance form.   This works great.

I have an Action object that allows maintenance on a table (call it table
A).   This action object handles "preloading of data"
as well as the actual "updating of data" (Add/Edit/View).

Another question I have:
- The action object gets kind of "kludgey" in how I have to keep track of
"whether I am preloading data (called from a html:link)" or whether I am
"Applying" the data (called from the form Submit).
Is it "overkill" if I create 2 different actions (1 action to preload the
data and another to "update" the data)?I think by doing it this way, it
may be easier for me to incorporate the "sensitive form resubmit"
prevention by using tokens.

Any suggestions are much appreciated.

thanks,
Theron


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

Struts design question about maintenance screens

[theron . kousek]

Hi Folks:

thanks to your help, you indicated that the Action should preload form
values on a maintenance form.   This works great.

I have an Action object that allows maintenance on a table (call it table
A).   This action object handles "preloading of data"
as well as the actual "updating of data" (Add/Edit/View).

Another question I have:
- The action object gets kind of "kludgey" in how I have to keep track of
"whether I am preloading data (called from a html:link)" or whether I am
"Applying" the data (called from the form Submit).
Is it "overkill" if I create 2 different actions (1 action to preload the
data and another to "update" the data)?I think by doing it this way, it
may be easier for me to incorporate the "sensitive form resubmit"
prevention by using tokens.

Any suggestions are much appreciated.

thanks,
Theron


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Design question about ActionForm's validate method

[Jonathan Gibbons]

Hi Ted,

I was implementing this and noticed a problem in V1.0.1

1.  Struts config is as below







2. The code for AdminSessionViewSrchAction does the following:

AdminSessionViewForm form_obj = 
sess_bean.maintainStrutSearchAdminSessionViewForm(params);
request.setAttribute("adminsessionviewForm", form_obj);
// Now want to forward to the correct jsp, including the params
return (mapping.findForward("display_row"));

3. OK, so we are seeing an action setting up the form for the following page, and that 
following page is being accessed via an ForwardAction, validate false.

Well, it doesn't work.   The prepopulated form does not display, all the fields have 
been reset to nothing.

4.  Is this a bug, or is this a problem with my config?  If display_row simlpy 
redirects to the jsp page directly then it works fine.

Jonathan




 Message History 



From: Ted Husted <[EMAIL PROTECTED]> on 06/02/2002 18:47 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Re: Design question about ActionForm's validate method


In 1.0.x, it is often suggested that each link at least be represented
by an ActionForward. This centralizes control over the hyperlinks in the
Struts Config, which yields a number of benefits.

In Struts 1.1, now the Nightly Build, support has been added for
multiple Struts configuration files. In order for this feature to work,
any request for a presentation page that uses elements from the
configuration file (ActionForms, forwards, mappings) must be routed
through the controller. This allows the controller to make the
appropriate configuration available for a given page.

This is becoming a common pattern, since the Velocity support, and I
believe the X2 servlet, also need you to do the same thing for the same
reason. The controller needs to touch the request to prepare it for the
presentation layer.

Many other features in advanced applications, including security,
logging, and screen definitins, are easier to implement when everything
passes through the controller.

In a strict MVC implementation, the controller is responsible for
interacting with the user. It then follows that all requests from the
user should flow through the controller. Some of us had been counting
the ActionForwards as flowing through the controller, but as the
framework expands, and more services are being plugged in, passing the
actual request through the controller becomes more and more desirable,
until it's really not worth making the occasional exception any more.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Alex Paransky wrote:
>
> So do you mean, all pages go through the Action?  Even those which are not
> forms and for display purposes only?  Could you shed some light as to why
> this is preferred?
>
> Thanks.
>
> -AP_
> http://www.alexparansky.com
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 2:02 PM
> To: Struts Users Mailing List
> Subject: Re: Design question about ActionForm's validate method
>
> The best practice now is to use ActionMappings for everything, so that
> the reqeust passes through the controller.
>
> This buys you several important capabilities that become important as
> applications grow. Not the least of which is the new support for
> multiple applications in the Nightly Build.
>
> The ActionMapping has a validate property that you can use to turn off
> validation when the mapping is used to initialize a new form. So,
> typically, you will have an ActionMapping for each circumstance.
>
>  path="/item/Add"
> type="org.apache.struts.actions.ForwardAction"
> parameter="/pages/item/Form.jsp">
> name="itemForm"
> scope="request"
> validate="false">
> 
>
> path="/item/Store"
> type="org.apache.gavel.item.http.Store"
> name="itemForm"
> scope="request"
> validate="true"
> input="/pages/item/Form.jsp"">
>      name="continue"
> path="/do/donor/Detail"/>
> 
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737

RE: Design question about ActionForm's validate method

[Alex Paransky]

Well, I went ahead and changed my code, so that all .jsp pages are accessed
through actions.  I am running into a particular problem and was hoping that
someone could help me out.

I have a page called "foo.jsp", I wrap it with a ForwardAction like this:



I also have a tag, which allows me to create a bean containing the current
URL (I use it for returnTo parameter to many forms).  In this tag, I use
request.getServletPath().  The problem, is that while the user's browser
reads "foo.do", my tag returns foo.jsp.  So when I use the resulting value
later, I am returned to foo.jsp and not foo.do.

Is there a way to fix this problem?

Thanks.
-AP_
http://www.alexparansky.com

-Original Message-
From: Sean Willson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 11:23 AM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


RE: Design question about ActionForm's validate method
The process we followed is very simular to what Ted suggested but depends on
how you are approaching the construction of your actions. If you have the
ability to write a collection of objects that handle storing and retreiving
data irreguardless of the data you might map it like this:

/do/store/address
/do/load/address
/do/load/user
etc ...

If however you want to segment it out as to what you are working on and then
the action you are performing on that thing you would merely reverse it to
this:

/do/address/load
/do/address/save
/do/address/delete

No what have we done in practice is a combination of those two. For one
project we were able to encapsulate the loading, sending, and saving type of
actions into one an action for each and thus the namespace we defined for
this was simular to the top  this namespace was a bit easier to manage
but obviously the actions themselves were either larger or the beans they
used were larger, for us the actions. For another larger project we went for
breadth as we didn't have much that was reusable and therefor had many many
actions all acting on the data but in different unique ways. Therefor the
namespace we defined was more in line with suggestion two.

One standard we have imposed which I think works and looks much cleaner is
the /do/* instead of *.do. It requires less explaining to people on what is
a .do file ... hehhe ... and it has less legacy implications like.cgi and
.pl have ... a namespace is nothing more then a mapping to a resource,
therefor extension has less importance. Anyhow ... we use /do/* for all
actions.

Not sure if any of this has helped ... ;)

Sean


- Original Message -
From: Alex Paransky
To: Struts Users Mailing List
Cc: [EMAIL PROTECTED]
Sent: Wednesday, February 06, 2002 11:53 PM
Subject: RE: Design question about ActionForm's validate method


Ok, I understand how forcing all requests through the controller is a good
thing.  Now, I have various types of pages:
Forms - http://www.alexparansky.com


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

Re: Design question about ActionForm's validate method

[Sean Willson]

RE: Design question about ActionForm's validate method
The process we followed is very simular to what Ted suggested but depends on
how you are approaching the construction of your actions. If you have the
ability to write a collection of objects that handle storing and retreiving
data irreguardless of the data you might map it like this:

/do/store/address
/do/load/address
/do/load/user
etc ...

If however you want to segment it out as to what you are working on and then
the action you are performing on that thing you would merely reverse it to
this:

/do/address/load
/do/address/save
/do/address/delete

No what have we done in practice is a combination of those two. For one
project we were able to encapsulate the loading, sending, and saving type of
actions into one an action for each and thus the namespace we defined for
this was simular to the top  this namespace was a bit easier to manage
but obviously the actions themselves were either larger or the beans they
used were larger, for us the actions. For another larger project we went for
breadth as we didn't have much that was reusable and therefor had many many
actions all acting on the data but in different unique ways. Therefor the
namespace we defined was more in line with suggestion two.

One standard we have imposed which I think works and looks much cleaner is
the /do/* instead of *.do. It requires less explaining to people on what is
a .do file ... hehhe ... and it has less legacy implications like.cgi and
.pl have ... a namespace is nothing more then a mapping to a resource,
therefor extension has less importance. Anyhow ... we use /do/* for all
actions.

Not sure if any of this has helped ... ;)

Sean


- Original Message -
From: Alex Paransky
To: Struts Users Mailing List
Cc: [EMAIL PROTECTED]
Sent: Wednesday, February 06, 2002 11:53 PM
Subject: RE: Design question about ActionForm's validate method


Ok, I understand how forcing all requests through the controller is a good
thing.  Now, I have various types of pages:
Forms - http://www.alexparansky.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Design question about ActionForm's validate method

[Ted Husted]

Unfortunately, we don't have free reign on conventions, and are
restricted to the patterns that the container will match. The container
gets the request first, and then passes it along to Struts. For the best
compatibility, a single, very simple pattern is best. 

One way to think about it is that the Actions are your applications API,
its command set. They represent everything that your application knows
how to do. One thing it does is display a form for adding a new record.
Another thing might to display a page summarizing the entered data, or a
page for editing the data. 

Displaying a form is sometimes a simple process. Often times, it is not,
since dropdown boxes must be populated, security parmeters might need to
be checked, other customizations might need to be performed. In
practice, there is sometimes a lot to do even to simply display a data
entry form. 

I tend to break my applications into modules, which sometimes correspond
to the major tables in a database, or at least the major databases
views. So I would tend to represent the URIs you mentioned as 

/adddress/Form.do
/address/Store.do
/address/View.do

or 

/do/adddress/Form
/do/address/Store
/do/address/View

-Ted.


Alex Paransky wrote:
> 
> Ok, I understand how forcing all requests through the controller is a good
> thing.  Now, I have various types of pages:
> 
> Forms -  Actions - .do action of the form
> View - basic .jsp page to view and link to a form for further edit
> 
> Is there a naming convention that you found works for you?  Since, I am
> using .do extension for everything, it seems like I have URL's which look
> like this:
> 
> AddressForm.do
> AddressSaveAction.do
> AddressView.do
> 
> I think it would be nice to have:
> 
> Address.form
> AddressSave.action
> Address.view
> 
> Or something like this.  The .do extension makes me think of "action" and I
> don't see a form or a view as an action.  I could always map *.view and
> *.form to execute the servlet as well, but then Address.form and
> Address.view are ambiguous.
> 
> Any suggestion on naming conventions?
> 
> Thanks.
> -AP_
> http://www.alexparansky.com
> 
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 06, 2002 3:47 PM
> To: Struts Users Mailing List
> Subject: Re: Design question about ActionForm's validate method
> 
> In 1.0.x, it is often suggested that each link at least be represented
> by an ActionForward. This centralizes control over the hyperlinks in the
> Struts Config, which yields a number of benefits.
> 
> In Struts 1.1, now the Nightly Build, support has been added for
> multiple Struts configuration files. In order for this feature to work,
> any request for a presentation page that uses elements from the
> configuration file (ActionForms, forwards, mappings) must be routed
> through the controller. This allows the controller to make the
> appropriate configuration available for a given page.
> 
> This is becoming a common pattern, since the Velocity support, and I
> believe the X2 servlet, also need you to do the same thing for the same
> reason. The controller needs to touch the request to prepare it for the
> presentation layer.
> 
> Many other features in advanced applications, including security,
> logging, and screen definitins, are easier to implement when everything
> passes through the controller.
> 
> In a strict MVC implementation, the controller is responsible for
> interacting with the user. It then follows that all requests from the
> user should flow through the controller. Some of us had been counting
> the ActionForwards as flowing through the controller, but as the
> framework expands, and more services are being plugged in, passing the
> actual request through the controller becomes more and more desirable,
> until it's really not worth making the occasional exception any more.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> Alex Paransky wrote:
> >
> > So do you mean, all pages go through the Action?  Even those which are not
> > forms and for display purposes only?  Could you shed some light as to why
> > this is preferred?
> >
> > Thanks.
> >
> > -AP_
> > http://www.alexparansky.com
> >
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 05, 2002 2:02 PM
> > To: Struts Users Mailing List
> > Subject: Re: Design question about ActionForm's validate method
> >
> > The best practice now is to use ActionMappings for everything, so that
> > the reqeust 

RE: Design question about ActionForm's validate method

[Alex Paransky]

Ok, I understand how forcing all requests through the controller is a good
thing.  Now, I have various types of pages:

Forms - http://www.alexparansky.com


-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 3:47 PM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


In 1.0.x, it is often suggested that each link at least be represented
by an ActionForward. This centralizes control over the hyperlinks in the
Struts Config, which yields a number of benefits.

In Struts 1.1, now the Nightly Build, support has been added for
multiple Struts configuration files. In order for this feature to work,
any request for a presentation page that uses elements from the
configuration file (ActionForms, forwards, mappings) must be routed
through the controller. This allows the controller to make the
appropriate configuration available for a given page.

This is becoming a common pattern, since the Velocity support, and I
believe the X2 servlet, also need you to do the same thing for the same
reason. The controller needs to touch the request to prepare it for the
presentation layer.

Many other features in advanced applications, including security,
logging, and screen definitins, are easier to implement when everything
passes through the controller.

In a strict MVC implementation, the controller is responsible for
interacting with the user. It then follows that all requests from the
user should flow through the controller. Some of us had been counting
the ActionForwards as flowing through the controller, but as the
framework expands, and more services are being plugged in, passing the
actual request through the controller becomes more and more desirable,
until it's really not worth making the occasional exception any more.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Alex Paransky wrote:
>
> So do you mean, all pages go through the Action?  Even those which are not
> forms and for display purposes only?  Could you shed some light as to why
> this is preferred?
>
> Thanks.
>
> -AP_
> http://www.alexparansky.com
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 2:02 PM
> To: Struts Users Mailing List
> Subject: Re: Design question about ActionForm's validate method
>
> The best practice now is to use ActionMappings for everything, so that
> the reqeust passes through the controller.
>
> This buys you several important capabilities that become important as
> applications grow. Not the least of which is the new support for
> multiple applications in the Nightly Build.
>
> The ActionMapping has a validate property that you can use to turn off
> validation when the mapping is used to initialize a new form. So,
> typically, you will have an ActionMapping for each circumstance.
>
>  path="/item/Add"
> type="org.apache.struts.actions.ForwardAction"
> parameter="/pages/item/Form.jsp">
> name="itemForm"
> scope="request"
> validate="false">
> 
>
> path="/item/Store"
> type="org.apache.gavel.item.http.Store"
> name="itemForm"
> scope="request"
> validate="true"
> input="/pages/item/Form.jsp"">
>  name="continue"
>     path="/do/donor/Detail"/>
> 
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> Sid Stuart wrote:
> >
> > Hi,
> >
> > I've stumbled across a subtle problem/design question that I don't see
> > mentioned in the documentation.
> >
> > The ActionForm's validate method can be configured to verify form data
> > from a page and generate error messages which may then be displayed on
> > the page for the user to see. This works fine when the user has accessed
> > the page by specifying a JSP file in the URL. When the user accesses the
> > page by calling the Action directly though, the validate method is
> > called before the user ever sees the page, much less inputs valid data
> > to the form. This leads to an unfortunate display of unwarranted error
> > messages.
> >
> > It would be nice if the documentation would provide a rule such as:
&

Re: Design question about ActionForm's validate method

[Ted Husted]

In 1.0.x, it is often suggested that each link at least be represented
by an ActionForward. This centralizes control over the hyperlinks in the
Struts Config, which yields a number of benefits. 

In Struts 1.1, now the Nightly Build, support has been added for
multiple Struts configuration files. In order for this feature to work,
any request for a presentation page that uses elements from the
configuration file (ActionForms, forwards, mappings) must be routed
through the controller. This allows the controller to make the
appropriate configuration available for a given page. 

This is becoming a common pattern, since the Velocity support, and I
believe the X2 servlet, also need you to do the same thing for the same
reason. The controller needs to touch the request to prepare it for the
presentation layer. 

Many other features in advanced applications, including security,
logging, and screen definitins, are easier to implement when everything
passes through the controller. 

In a strict MVC implementation, the controller is responsible for
interacting with the user. It then follows that all requests from the
user should flow through the controller. Some of us had been counting
the ActionForwards as flowing through the controller, but as the
framework expands, and more services are being plugged in, passing the
actual request through the controller becomes more and more desirable,
until it's really not worth making the occasional exception any more. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Alex Paransky wrote:
> 
> So do you mean, all pages go through the Action?  Even those which are not
> forms and for display purposes only?  Could you shed some light as to why
> this is preferred?
> 
> Thanks.
> 
> -AP_
> http://www.alexparansky.com
> 
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 2:02 PM
> To: Struts Users Mailing List
> Subject: Re: Design question about ActionForm's validate method
> 
> The best practice now is to use ActionMappings for everything, so that
> the reqeust passes through the controller.
> 
> This buys you several important capabilities that become important as
> applications grow. Not the least of which is the new support for
> multiple applications in the Nightly Build.
> 
> The ActionMapping has a validate property that you can use to turn off
> validation when the mapping is used to initialize a new form. So,
> typically, you will have an ActionMapping for each circumstance.
> 
>  path="/item/Add"
> type="org.apache.struts.actions.ForwardAction"
> parameter="/pages/item/Form.jsp">
> name="itemForm"
> scope="request"
> validate="false">
> 
> 
> path="/item/Store"
> type="org.apache.gavel.item.http.Store"
> name="itemForm"
> scope="request"
> validate="true"
> input="/pages/item/Form.jsp"">
>  name="continue"
> path="/do/donor/Detail"/>
> 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
> 
> Sid Stuart wrote:
> >
> > Hi,
> >
> > I've stumbled across a subtle problem/design question that I don't see
> > mentioned in the documentation.
> >
> > The ActionForm's validate method can be configured to verify form data
> > from a page and generate error messages which may then be displayed on
> > the page for the user to see. This works fine when the user has accessed
> > the page by specifying a JSP file in the URL. When the user accesses the
> > page by calling the Action directly though, the validate method is
> > called before the user ever sees the page, much less inputs valid data
> > to the form. This leads to an unfortunate display of unwarranted error
> > messages.
> >
> > It would be nice if the documentation would provide a rule such as:
> > If one plans on the user calling the Action directly in the URL  then
> > one should not use the automatic validation provided by ActionForm.
> >
> > Further, as having two different procedures to generate a page can lead
> > to subtle errors, one should decide whether a page will be accessed as a
> > JSP or as an Actio

RE: Design question about ActionForm's validate method

[Greg Hess]

I would like to see some examples, I have found my apps to be a bit bloated
since introducing struts and my Action classes are very small.

Thanks

-Original Message-
From: Sean Willson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 9:06 AM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


RE: Design question about ActionForm's validate methodFor reference I wanted
to share how we are using the action framework in our web application. Every
single call to every single view on our web site goes through Struts. There
are several reasons for this, one we are using Tiles for navigation and
since they are not as tightly integrated as I would like we had to do this.
Another is that every single view has data that needs to be prepopulated
before it can be displayed. Rather than create 2 actions for each view (one
for the loading and one for the saving) we encapsulated this logic in one
action. One of the first things it does is call a method called
isSubmission(request) ... this method interrogates the request to see if
there are any parameters that it considers "new" and not related to a load,
if it found some it would then assume it is a submission. If there are none,
it assumes it is a load and thus loads all of the data from the database and
other sources. If however it sees data on the hook that it doesn't
recognize, it then behaves as a submission and attempts to perform a save.
This has worked rather well overall.

To facilitate this we create a root action that has this method
(isSubmission) and in there we can specify parameters that we want ALL
action to handle, like a successRedirect parameter that should be used in
the event a submission is successfully saved. The same can be said for a
root level form that all of our forms subclass from to tie in those
attributes added to the check in isSubmission.

Some may argue that this is a mix between the model and the controller logic
but I don't agree. I think if you look at anyone's actions you will see a
little overlap, since Struts itself isn't a pure clean line of separation.
The key is getting it to work for you and your clients while still
maintaining some future vision and control over the architecture and not
letting it get out of hand.

I you want some code examples of this I can likely throw some together.

Sean


- Original Message -
From: Matt Read
To: Struts Users Mailing List
Sent: Tuesday, February 05, 2002 11:59 AM
Subject: RE: Design question about ActionForm's validate method


I'm fairly new to struts (well, about 24 hours actually) and this message
touches on a concept that I've having trouble grasping.
Are you saying that your site should never allow the user to navigate to a
URL that maps to an Action unless you are submitting a form?
This is my example and although it's actually working in practice it doesn't
really feel right to me and doesn't conform to above rule. I hope I've
included enough detail and would appreciate any clues on good design.
1. User goes to the home page and clicks on a "Find a client" link.
2. This link points to "/find/client.do" which is defined as an
ActionMapping as follows:



3. The code in FindClientAction ensures that the user is authenticated and
then populates some request scoped attributes that enabled
/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a
form to allow the user to enter search criteria.
4. The submit action for the form in /pages/findClient.jsp is
"/find/getresults" which is defined as an ActionMapping as follows:



5. The code in FindClientResultsAction examines the contents of the
clientFindForm and contstructs a SQL statement to retrieve the correct data.
6. /pages/findClientResults.jsp renders the results from the database.
Matt.


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

Re: Design question about ActionForm's validate method

[Sean Willson]

RE: Design question about ActionForm's validate methodFor reference I wanted
to share how we are using the action framework in our web application. Every
single call to every single view on our web site goes through Struts. There
are several reasons for this, one we are using Tiles for navigation and
since they are not as tightly integrated as I would like we had to do this.
Another is that every single view has data that needs to be prepopulated
before it can be displayed. Rather than create 2 actions for each view (one
for the loading and one for the saving) we encapsulated this logic in one
action. One of the first things it does is call a method called
isSubmission(request) ... this method interrogates the request to see if
there are any parameters that it considers "new" and not related to a load,
if it found some it would then assume it is a submission. If there are none,
it assumes it is a load and thus loads all of the data from the database and
other sources. If however it sees data on the hook that it doesn't
recognize, it then behaves as a submission and attempts to perform a save.
This has worked rather well overall.

To facilitate this we create a root action that has this method
(isSubmission) and in there we can specify parameters that we want ALL
action to handle, like a successRedirect parameter that should be used in
the event a submission is successfully saved. The same can be said for a
root level form that all of our forms subclass from to tie in those
attributes added to the check in isSubmission.

Some may argue that this is a mix between the model and the controller logic
but I don't agree. I think if you look at anyone's actions you will see a
little overlap, since Struts itself isn't a pure clean line of separation.
The key is getting it to work for you and your clients while still
maintaining some future vision and control over the architecture and not
letting it get out of hand.

I you want some code examples of this I can likely throw some together.

Sean


- Original Message -
From: Matt Read
To: Struts Users Mailing List
Sent: Tuesday, February 05, 2002 11:59 AM
Subject: RE: Design question about ActionForm's validate method


I'm fairly new to struts (well, about 24 hours actually) and this message
touches on a concept that I've having trouble grasping.
Are you saying that your site should never allow the user to navigate to a
URL that maps to an Action unless you are submitting a form?
This is my example and although it's actually working in practice it doesn't
really feel right to me and doesn't conform to above rule. I hope I've
included enough detail and would appreciate any clues on good design.
1. User goes to the home page and clicks on a "Find a client" link.
2. This link points to "/find/client.do" which is defined as an
ActionMapping as follows:



3. The code in FindClientAction ensures that the user is authenticated and
then populates some request scoped attributes that enabled
/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a
form to allow the user to enter search criteria.
4. The submit action for the form in /pages/findClient.jsp is
"/find/getresults" which is defined as an ActionMapping as follows:



5. The code in FindClientResultsAction examines the contents of the
clientFindForm and contstructs a SQL statement to retrieve the correct data.
6. /pages/findClientResults.jsp renders the results from the database.
Matt.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Design question about ActionForm's validate method

[Jonathan Gibbons]

Hi,

live and learn eh!   I revise my recommendation, you still need two URL's, but they 
can go to defined action paths.

However, beware of users browsing directly to the JSP's and code with that in mind.   
Also to stop yourself going mad, make sure the GET path and POST path are different

eg GET
/jsp/apageGet

POST
/jsp/apagePost.do

Jonathan
ps now rewritting my code gen.


 Message History 



From: "Robert Scaduto" <[EMAIL PROTECTED]> on 05/02/2002 13:31 EST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject:  RE: Design question about ActionForm's validate method


Matt,

I also disagree that you should only use actions when submitting a form.  I
also believe that in most cases you should never forward a request directly
to a jsp without first going through the Action framework.

Struts provides a utility action that will do this for you.  The
org.apache.struts.actions.ForwardAction will forward to the jsp file
specified in the parameter attribute of the action mapping. Like so..




If you are using the *.do extension in your servlet mapping you would access
the action like this...

Go to Password
Assistance

It may seem like extra work for no reason but if the requirements of your
system change and now you need to forward to an action instead of a jsp it
is much easier to replace the ForwardAction to a custom action.

It sounds to me like you are on the right track.

-Rob

-Original Message-
From: Matt Read [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:59 PM
To: Struts Users Mailing List
Subject: RE: Design question about ActionForm's validate method


I'm fairly new to struts (well, about 24 hours actually) and this message
touches on a concept that I've having trouble grasping.

Are you saying that your site should never allow the user to navigate to a
URL that maps to an Action unless you are submitting a form?

This is my example and although it's actually working in practice it doesn't
really feel right to me and doesn't conform to above rule. I hope I've
included enough detail and would appreciate any clues on good design.

1. User goes to the home page and clicks on a "Find a client" link.
2. This link points to "/find/client.do" which is defined as an
ActionMapping as follows:
 
   
 
3. The code in FindClientAction ensures that the user is authenticated and
then populates some request scoped attributes that enabled
/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a
form to allow the user to enter search criteria.
4. The submit action for the form in /pages/findClient.jsp is
"/find/getresults" which is defined as an ActionMapping as follows:

   

5. The code in FindClientResultsAction examines the contents of the
clientFindForm and contstructs a SQL statement to retrieve the correct data.
6. /pages/findClientResults.jsp renders the results from the database.

Matt.

-Original Message-
From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
Sent: 05 February 2002 17:44
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method



I made this same 'mistake'.

Actions MUST only be called when a form is submitted.   Never to generate
the JSP.  Thats why they are called actions.

Or two put it another way, you do need several URL's

a) URL to JSP on a GET
b) URL to action the POST

The easiert way to do it is to have all forwards going directly to the JSP,
and all actions in the pages going to .do.

At first it seems rubish, but then you hopefully buy into the model view
controller idea.  i.e NO business logic in the page and it all starts to
make perfect sence.   But you really do have to buy into it otherwise you
are fighting urge to ditch it all and go back to brilliant servlets, nice
and easy, total power etc etc.

Jonathan


 Message
History 


From: Sid Stuart <[EMAIL PROTECTED]> on 05/02/2002 09:24 PST

Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Design question about ActionForm's validate method


Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the

RE: Design question about ActionForm's validate method

[Alex Paransky]

So do you mean, all pages go through the Action?  Even those which are not
forms and for display purposes only?  Could you shed some light as to why
this is preferred?

Thanks.

-AP_
http://www.alexparansky.com


-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 2:02 PM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


The best practice now is to use ActionMappings for everything, so that
the reqeust passes through the controller.

This buys you several important capabilities that become important as
applications grow. Not the least of which is the new support for
multiple applications in the Nightly Build.

The ActionMapping has a validate property that you can use to turn off
validation when the mapping is used to initialize a new form. So,
typically, you will have an ActionMapping for each circumstance.


name="itemForm"
scope="request"
validate="false">


   



-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Sid Stuart wrote:
>
> Hi,
>
> I've stumbled across a subtle problem/design question that I don't see
> mentioned in the documentation.
>
> The ActionForm's validate method can be configured to verify form data
> from a page and generate error messages which may then be displayed on
> the page for the user to see. This works fine when the user has accessed
> the page by specifying a JSP file in the URL. When the user accesses the
> page by calling the Action directly though, the validate method is
> called before the user ever sees the page, much less inputs valid data
> to the form. This leads to an unfortunate display of unwarranted error
> messages.
>
> It would be nice if the documentation would provide a rule such as:
> If one plans on the user calling the Action directly in the URL  then
> one should not use the automatic validation provided by ActionForm.
>
> Further, as having two different procedures to generate a page can lead
> to subtle errors, one should decide whether a page will be accessed as a
> JSP or as an Action and design for the one scenario. The simplest (and
> safest) design rule will be to access all pages through either one
> mechanism or the other.
>
> Comments?
>
> Sid Stuart

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

RE: RE: Design question about ActionForm's validate method

[ykphuah]

Hi,

I think there is some misconfiguration issue, as far as I know,
there are two kind of actions in Struts, EditAction and
SaveAction. For my implementation, all the EditAction
have validate=false in the struts-config.xml and all the
SaveAction have validate=true.

EditAction took care of 2 operations, edit and add, for
add, it just instantiate an object, for edit operation, it have
to load the values from the persistence layer (loading from JSP
is surely a very ugly thing to do.).

So for EditAction, its just plainly creating and loading,
no validation is neccessary, for SaveAction, then we need
validation.

CHeers,
Yee Keat

- Original Message -
From: "Robert Scaduto" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List"
<[EMAIL PROTECTED]>
Sent: Feb 6, 2002 2:31:19 AM GMT+08:00
Subject: RE: Design question about ActionForm's validate method

>Matt,
>
>I also disagree that you should only use actions when
submitting a form.  I
>also believe that in most cases you should never forward a
request directly
>to a jsp without first going through the Action framework.
>
>Struts provides a utility action that will do this for you. 
The
>org.apache.struts.actions.ForwardAction will forward to the
jsp file
>specified in the parameter attribute of the action mapping.
Like so..
>
>   type="org.apache.struts.actions.ForwardAction"
>   parameter="/password_assistance.jsp">
>
>
>If you are using the *.do extension in your servlet mapping
you would access
>the action like this...
>
>Go to Password
>Assistance
>
>It may seem like extra work for no reason but if the
requirements of your
>system change and now you need to forward to an action instead
of a jsp it
>is much easier to replace the ForwardAction to a custom
action.
>
>It sounds to me like you are on the right track.
>
>-Rob
>
>-Original Message-
>From: Matt Read [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 05, 2002 12:59 PM
>To: Struts Users Mailing List
>Subject: RE: Design question about ActionForm's validate
method
>
>
>I'm fairly new to struts (well, about 24 hours actually) and
this message
>touches on a concept that I've having trouble grasping.
>
>Are you saying that your site should never allow the user to
navigate to a
>URL that maps to an Action unless you are submitting a form?
>
>This is my example and although it's actually working in
practice it doesn't
>really feel right to me and doesn't conform to above rule. I
hope I've
>included enough detail and would appreciate any clues on good
design.
>
>1. User goes to the home page and clicks on a "Find a client"
link.
>2. This link points to "/find/client.do" which is defined as
an
>ActionMapping as follows:
>  type="mysite.actions.FindClientAction"
>   name="clientFindForm"
>   scope="request"
>   input="/pages/findclient.jsp">
>   
>   
>3. The code in FindClientAction ensures that the user is
authenticated and
>then populates some request scoped attributes that enabled
>/pages/findClient.jsp to function correctly.
/pagesfindClient.jsp displays a
>form to allow the user to enter search criteria.
>4. The submit action for the form in /pages/findClient.jsp is
>"/find/getresults" which is defined as an ActionMapping as
follows:
>   type="mysite.actions.FindClientResultsAction"
>   name="clientFindForm"
>   scope="request"
>   input="/pages/findclient.jsp">
>   
>
>5. The code in FindClientResultsAction examines the contents
of the
>clientFindForm and contstructs a SQL statement to retrieve the
correct data.
>6. /pages/findClientResults.jsp renders the results from the
database.
>
>Matt.
>
>-Original Message-
>From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
>Sent: 05 February 2002 17:44
>To: Struts Users Mailing List
>Subject: Re: Design question about ActionForm's validate
method
>
>
>
>I made this same 'mistake'.
>
>Actions MUST only be called when a form is submitted.   Never
to generate
>the JSP.  Thats why they are called actions.
>
>Or two put it another way, you do need several URL's
>
>a) URL to JSP on a GET
>b) URL to action the POST
>
>The easiert way to do it is to have all forwards going
directly to the JSP,
>and all actions in the pages going to .do.
>
>At first it seems rubish, but then you hopefu

MessageResources - Design question - loading resources from a DB by creating you own PropertyMessageResourcesFactory

[Todd G. Nist]

Hello,

First, I would like to apologize for the size of this post.  I seem to be
missing one thing here and can't seem to put my finger on it.

We have a database which contains most of the translations for our
applications messages and database fields/column labels.  There is one table
which contains the messages, ApplicationResources, and another table called
field which contains general information about a field/column in the
database.  The field table is really only there to provide basic metadata
about columns like, the Column/Field label and some other basic information
which certain DB's do not provide.

There is one other table, Translations, which is made up of 3 columns
locale, stringID and transValue.

ApplicationResourcesTranslationsField
-   
---
| key (pu) varchar || transValuevarchar |   | fieldID (pu) int 
|   |
| message  varchar |-<| stringID (pu) varchar |>| fieldLabel
(pu) varchar |
| locale (pu)   varchar |   | fieldName (pu) 
varchar  |
-   
---

I would like to load this information via my on
PropertyMessageResourcesFactory.  I have modified the web.xml to set the
parameter "factory" and set the  to my factory class,
DBMessageResourcesFactory.  The factory is called and my class,
BasePropertyMessageResources, is called and it appears as though all is
loaded in correctly based on the output being displayed below.  However,
whenever I use the  tag, it throws the
following exception:

[ServletException in:company/CompanyZoomBody.jsp] Missing message for key
MLSBuyer.title' javax.servlet.jsp.JspException: Missing message for key
MLSBuyer.title at
org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag.java:298) at
org.apache.jsp.CompanyZoomBody$jsp._jspService(CompanyZoomBody$jsp.java:84)
at 

Debugging messages displayed during execution:

===
Config: ApplicationResources
===
Completed BasePropertyMessageResources
Get MessageResources for key: org.apache.struts.action.MESSAGE
loading the following key: US.MLSBuyer.title with value MLSBuyer
loading the following key: US.button.cancel with value Cancel
loading the following key: US.button.save with value Save
loading the following key: US.button.update with value Update
loading the following key: FR.MLSBuyer.title with value MLSBuyer - French
loading the following key: FR.button.cancel with value FR Cancel
loading the following key: FR.button.save with value FR Save
loading the following key: FR.button.update with value FR Update
loading the following key: FR.MLSBuyer.title with value MLSBuyer - French
loading the following key: FR.button.cancel with value FR Cancel
loading the following key: FR.button.save with value FR Save
loading the following key: FR.button.update with value FR Update
loading the following key: US.CompanyName with value Company Name
loading the following key: FR.CompanyName with value French Company Name
loading the following key: FR.CompanyName with value French Company Name
===
/* Closing Translation Connection
===
===
/* Iterate over messages
===
US.button.cancelCancel
US.CompanyName  Company Name
US.button.save  Save
FR.button.updateFR Update
US.button.updateUpdate
FR.CompanyName  French Company Name
US.MLSBuyer.title   MLSBuyer
FR.button.cancelFR Cancel
FR.MLSBuyer.title   MLSBuyer - French
FR.button.save  FR Save

I have extend the ActionServlet class and added the following
"initApplication()" method, this much seems to work fine.

public void initApplication() throws ServletException {
super.initApplication();

String dataSource =
getServletConfig().getInitParameter("datasource");

if (dataSource != null && !dataSource.equals("")) {
getServletContext().setAttribute("DATASOURCE", dataSource);
}

System.out.println("Get MessageResources for key: " +
Action.MESSAGES_KEY);
MessageResources mr =
(MessageResources)getServletContext().getAttribute(Action.MESSAGES_KEY);

if (mr == null) {
System.out.println("Message Resource is invalid");
return;
}
  // load resources from the dataSource
((BasePropertyMessageResources)mr).dbLoad(dataSource);

}

The MessageResources classs, BasePropertyMessageResources, is as follows and
seems to build messages just fine:

public class BasePropertyMessageResources extends PropertyMessageResources {

private static final Category log =
Category.getInstance("BaseProperyMessageResources");

private static final String[

Re: Design question about ActionForm's validate method

[Ted Husted]

The best practice now is to use ActionMappings for everything, so that
the reqeust passes through the controller. 

This buys you several important capabilities that become important as
applications grow. Not the least of which is the new support for
multiple applications in the Nightly Build. 

The ActionMapping has a validate property that you can use to turn off
validation when the mapping is used to initialize a new form. So,
typically, you will have an ActionMapping for each circumstance. 


name="itemForm"
scope="request"
validate="false">


   
 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


Sid Stuart wrote:
> 
> Hi,
> 
> I've stumbled across a subtle problem/design question that I don't see
> mentioned in the documentation.
> 
> The ActionForm's validate method can be configured to verify form data
> from a page and generate error messages which may then be displayed on
> the page for the user to see. This works fine when the user has accessed
> the page by specifying a JSP file in the URL. When the user accesses the
> page by calling the Action directly though, the validate method is
> called before the user ever sees the page, much less inputs valid data
> to the form. This leads to an unfortunate display of unwarranted error
> messages.
> 
> It would be nice if the documentation would provide a rule such as:
> If one plans on the user calling the Action directly in the URL  then
> one should not use the automatic validation provided by ActionForm.
> 
> Further, as having two different procedures to generate a page can lead
> to subtle errors, one should decide whether a page will be accessed as a
> JSP or as an Action and design for the one scenario. The simplest (and
> safest) design rule will be to access all pages through either one
> mechanism or the other.
> 
> Comments?
> 
> Sid Stuart

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Design question about ActionForm's validate method

[Greg Hess]

Unfortunatly not all html input fields are populated in the http request by
default. Radio Buttons and Check boxes will be null if the user did not
select the option.

-Original Message-
From: Sid Stuart [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 2:56 PM
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method


You get a zero length string.

Sid

dderry wrote:

> What if your user then hits the Submit button without populating any of
the
> form fields?
>
> - Original Message -
> From: "Sid Stuart" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Tuesday, February 05, 2002 2:06 PM
> Subject: Re: Design question about ActionForm's validate method
>
> > Hi,
> >
> > My friend, Lee Crawford, just pointed out to me that the fields of the
> > ActionForm will be null if the validate method is called before the form
> is
> > submitted, but will be non-null afterwards. This provides a quick and
> simple
> > test that works for JSP called pages and for Action called pages,
> >
> >
> >public ActionErrors validate (ActionMapping mapping,
> >  HttpServletRequest request) {
> >  // See if the form has been submitted, if not do not
> >  validate.
> >  if (logon == null || password == null ) return null;
> >  // Validate the data
> >  final ActionErrors errors = new ActionErrors ();
> >  if (logon.length() < 1) {
> >  errors.add ("logon", new ActionError
> >  ("error.logon.logonRequired"));
> >  }
> >  if (password.length() < 1) {
> >  errors.add("password", new ActionError
> >  ("error.logon.passwordRequired"));
> >  }
> >  return errors;
> >  }
> >
> >
> > Sid
> >
> >
>
> --
> 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]>

Re: Design question about ActionForm's validate method

[dderry]

True, so I guess the null test will work.


- Original Message -
From: "Sid Stuart" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 2:55 PM
Subject: Re: Design question about ActionForm's validate method


> You get a zero length string.
>
> Sid
>
> dderry wrote:
>
> > What if your user then hits the Submit button without populating any of
the
> > form fields?
> >
> > - Original Message -
> > From: "Sid Stuart" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, February 05, 2002 2:06 PM
> > Subject: Re: Design question about ActionForm's validate method
> >
> > > Hi,
> > >
> > > My friend, Lee Crawford, just pointed out to me that the fields of the
> > > ActionForm will be null if the validate method is called before the
form
> > is
> > > submitted, but will be non-null afterwards. This provides a quick and
> > simple
> > > test that works for JSP called pages and for Action called pages,
> > >
> > >
> > >public ActionErrors validate (ActionMapping mapping,
> > >  HttpServletRequest request) {
> > >  // See if the form has been submitted, if not do not
> > >  validate.
> > >  if (logon == null || password == null ) return null;
> > >  // Validate the data
> > >  final ActionErrors errors = new ActionErrors ();
> > >  if (logon.length() < 1) {
> > >  errors.add ("logon", new ActionError
> > >  ("error.logon.logonRequired"));
> > >  }
> > >  if (password.length() < 1) {
> > >  errors.add("password", new ActionError
> > >  ("error.logon.passwordRequired"));
> > >  }
> > >  return errors;
> > >  }
> > >
> > >
> > > Sid
> > >
> > >
> >
> > --
> > 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]>

Re: Design question about ActionForm's validate method

[Sid Stuart]

You get a zero length string.

Sid

dderry wrote:

> What if your user then hits the Submit button without populating any of the
> form fields?
>
> - Original Message -
> From: "Sid Stuart" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Tuesday, February 05, 2002 2:06 PM
> Subject: Re: Design question about ActionForm's validate method
>
> > Hi,
> >
> > My friend, Lee Crawford, just pointed out to me that the fields of the
> > ActionForm will be null if the validate method is called before the form
> is
> > submitted, but will be non-null afterwards. This provides a quick and
> simple
> > test that works for JSP called pages and for Action called pages,
> >
> >
> >public ActionErrors validate (ActionMapping mapping,
> >  HttpServletRequest request) {
> >  // See if the form has been submitted, if not do not
> >  validate.
> >  if (logon == null || password == null ) return null;
> >  // Validate the data
> >  final ActionErrors errors = new ActionErrors ();
> >  if (logon.length() < 1) {
> >  errors.add ("logon", new ActionError
> >  ("error.logon.logonRequired"));
> >  }
> >  if (password.length() < 1) {
> >  errors.add("password", new ActionError
> >  ("error.logon.passwordRequired"));
> >  }
> >  return errors;
> >  }
> >
> >
> > Sid
> >
> >
>
> --
> 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]>

Re: Design question about ActionForm's validate method

[dderry]

What if your user then hits the Submit button without populating any of the
form fields?


- Original Message -
From: "Sid Stuart" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 2:06 PM
Subject: Re: Design question about ActionForm's validate method


> Hi,
>
> My friend, Lee Crawford, just pointed out to me that the fields of the
> ActionForm will be null if the validate method is called before the form
is
> submitted, but will be non-null afterwards. This provides a quick and
simple
> test that works for JSP called pages and for Action called pages,
>
>
>public ActionErrors validate (ActionMapping mapping,
>  HttpServletRequest request) {
>  // See if the form has been submitted, if not do not
>  validate.
>  if (logon == null || password == null ) return null;
>  // Validate the data
>  final ActionErrors errors = new ActionErrors ();
>  if (logon.length() < 1) {
>  errors.add ("logon", new ActionError
>  ("error.logon.logonRequired"));
>  }
>  if (password.length() < 1) {
>  errors.add("password", new ActionError
>  ("error.logon.passwordRequired"));
>  }
>  return errors;
>  }
>
>
> Sid
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Design question about ActionForm's validate method

[Sid Stuart]

Hi,

My friend, Lee Crawford, just pointed out to me that the fields of the
ActionForm will be null if the validate method is called before the form is
submitted, but will be non-null afterwards. This provides a quick and simple
test that works for JSP called pages and for Action called pages,


   public ActionErrors validate (ActionMapping mapping,
 HttpServletRequest request) {
 // See if the form has been submitted, if not do not
 validate.
 if (logon == null || password == null ) return null;
 // Validate the data
 final ActionErrors errors = new ActionErrors ();
 if (logon.length() < 1) {
 errors.add ("logon", new ActionError
 ("error.logon.logonRequired"));
 }
 if (password.length() < 1) {
 errors.add("password", new ActionError
 ("error.logon.passwordRequired"));
 }
 return errors;
 }


Sid

Sid Stuart wrote:

> Hi,
>
> I've stumbled across a subtle problem/design question that I don't see
> mentioned in the documentation.
>
> The ActionForm's validate method can be configured to verify form data
> from a page and generate error messages which may then be displayed on
> the page for the user to see. This works fine when the user has accessed
> the page by specifying a JSP file in the URL. When the user accesses the
> page by calling the Action directly though, the validate method is
> called before the user ever sees the page, much less inputs valid data
> to the form. This leads to an unfortunate display of unwarranted error
> messages.
>
> It would be nice if the documentation would provide a rule such as:
> If one plans on the user calling the Action directly in the URL  then
> one should not use the automatic validation provided by ActionForm.
>
> Further, as having two different procedures to generate a page can lead
> to subtle errors, one should decide whether a page will be accessed as a
> JSP or as an Action and design for the one scenario. The simplest (and
> safest) design rule will be to access all pages through either one
> mechanism or the other.
>
> Comments?
>
> Sid Stuart

RE: Design question about ActionForm's validate method

[Robert Scaduto]

Matt,

I also disagree that you should only use actions when submitting a form.  I
also believe that in most cases you should never forward a request directly
to a jsp without first going through the Action framework.

Struts provides a utility action that will do this for you.  The
org.apache.struts.actions.ForwardAction will forward to the jsp file
specified in the parameter attribute of the action mapping. Like so..




If you are using the *.do extension in your servlet mapping you would access
the action like this...

Go to Password
Assistance

It may seem like extra work for no reason but if the requirements of your
system change and now you need to forward to an action instead of a jsp it
is much easier to replace the ForwardAction to a custom action.

It sounds to me like you are on the right track.

-Rob

-Original Message-
From: Matt Read [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:59 PM
To: Struts Users Mailing List
Subject: RE: Design question about ActionForm's validate method


I'm fairly new to struts (well, about 24 hours actually) and this message
touches on a concept that I've having trouble grasping.

Are you saying that your site should never allow the user to navigate to a
URL that maps to an Action unless you are submitting a form?

This is my example and although it's actually working in practice it doesn't
really feel right to me and doesn't conform to above rule. I hope I've
included enough detail and would appreciate any clues on good design.

1. User goes to the home page and clicks on a "Find a client" link.
2. This link points to "/find/client.do" which is defined as an
ActionMapping as follows:



3. The code in FindClientAction ensures that the user is authenticated and
then populates some request scoped attributes that enabled
/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a
form to allow the user to enter search criteria.
4. The submit action for the form in /pages/findClient.jsp is
"/find/getresults" which is defined as an ActionMapping as follows:



5. The code in FindClientResultsAction examines the contents of the
clientFindForm and contstructs a SQL statement to retrieve the correct data.
6. /pages/findClientResults.jsp renders the results from the database.

Matt.

-Original Message-
From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
Sent: 05 February 2002 17:44
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method



I made this same 'mistake'.

Actions MUST only be called when a form is submitted.   Never to generate
the JSP.  Thats why they are called actions.

Or two put it another way, you do need several URL's

a) URL to JSP on a GET
b) URL to action the POST

The easiert way to do it is to have all forwards going directly to the JSP,
and all actions in the pages going to .do.

At first it seems rubish, but then you hopefully buy into the model view
controller idea.  i.e NO business logic in the page and it all starts to
make perfect sence.   But you really do have to buy into it otherwise you
are fighting urge to ditch it all and go back to brilliant servlets, nice
and easy, total power etc etc.

Jonathan


 Message
History 


From: Sid Stuart <[EMAIL PROTECTED]> on 05/02/2002 09:24 PST

Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Design question about ActionForm's validate method


Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the validate method is
called before the user ever sees the page, much less inputs valid data
to the form. This leads to an unfortunate display of unwarranted error
messages.

It would be nice if the documentation would provide a rule such as:
If one plans on the user calling the Action directly in the URL  then
one should not use the automatic validation provided by ActionForm.

Further, as having two different procedures to generate a page can lead
to subtle errors, one should decide whether a page will be accessed as a
JSP or as an Action and design for the one scenario. The simplest (and
safest) design rule will be to access all pages through either one
mechanism or the other.

Comments?

Sid Stuart








--

This e-mail may contain confidential and/or privileged inform

RE: Design question about ActionForm's validate method

[Matt Read]

I'm fairly new to struts (well, about 24 hours actually) and this message
touches on a concept that I've having trouble grasping.

Are you saying that your site should never allow the user to navigate to a
URL that maps to an Action unless you are submitting a form?

This is my example and although it's actually working in practice it doesn't
really feel right to me and doesn't conform to above rule. I hope I've
included enough detail and would appreciate any clues on good design.

1. User goes to the home page and clicks on a "Find a client" link.
2. This link points to "/find/client.do" which is defined as an
ActionMapping as follows:



3. The code in FindClientAction ensures that the user is authenticated and
then populates some request scoped attributes that enabled
/pages/findClient.jsp to function correctly. /pagesfindClient.jsp displays a
form to allow the user to enter search criteria.
4. The submit action for the form in /pages/findClient.jsp is
"/find/getresults" which is defined as an ActionMapping as follows:



5. The code in FindClientResultsAction examines the contents of the
clientFindForm and contstructs a SQL statement to retrieve the correct data.
6. /pages/findClientResults.jsp renders the results from the database.

Matt.

-Original Message-
From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]]
Sent: 05 February 2002 17:44
To: Struts Users Mailing List
Subject: Re: Design question about ActionForm's validate method



I made this same 'mistake'.

Actions MUST only be called when a form is submitted.   Never to generate
the JSP.  Thats why they are called actions.

Or two put it another way, you do need several URL's

a) URL to JSP on a GET
b) URL to action the POST

The easiert way to do it is to have all forwards going directly to the JSP,
and all actions in the pages going to .do.

At first it seems rubish, but then you hopefully buy into the model view
controller idea.  i.e NO business logic in the page and it all starts to
make perfect sence.   But you really do have to buy into it otherwise you
are fighting urge to ditch it all and go back to brilliant servlets, nice
and easy, total power etc etc.

Jonathan


 Message
History 


From: Sid Stuart <[EMAIL PROTECTED]> on 05/02/2002 09:24 PST

Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Design question about ActionForm's validate method


Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the validate method is
called before the user ever sees the page, much less inputs valid data
to the form. This leads to an unfortunate display of unwarranted error
messages.

It would be nice if the documentation would provide a rule such as:
If one plans on the user calling the Action directly in the URL  then
one should not use the automatic validation provided by ActionForm.

Further, as having two different procedures to generate a page can lead
to subtle errors, one should decide whether a page will be accessed as a
JSP or as an Action and design for the one scenario. The simplest (and
safest) design rule will be to access all pages through either one
mechanism or the other.

Comments?

Sid Stuart








--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.



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

Re: Design question about ActionForm's validate method

[Jonathan Gibbons]

I made this same 'mistake'.

Actions MUST only be called when a form is submitted.   Never to generate the JSP.  
Thats why they are called actions.

Or two put it another way, you do need several URL's

a) URL to JSP on a GET
b) URL to action the POST

The easiert way to do it is to have all forwards going directly to the JSP, and all 
actions in the pages going to .do.

At first it seems rubish, but then you hopefully buy into the model view controller 
idea.  i.e NO business logic in the page and it all starts to make perfect sence.   
But you really do have to buy into it otherwise you are fighting urge to ditch it all 
and go back to brilliant servlets, nice and easy, total power etc etc.

Jonathan


 Message History 



From: Sid Stuart <[EMAIL PROTECTED]> on 05/02/2002 09:24 PST

Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]>

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Design question about ActionForm's validate method


Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the validate method is
called before the user ever sees the page, much less inputs valid data
to the form. This leads to an unfortunate display of unwarranted error
messages.

It would be nice if the documentation would provide a rule such as:
If one plans on the user calling the Action directly in the URL  then
one should not use the automatic validation provided by ActionForm.

Further, as having two different procedures to generate a page can lead
to subtle errors, one should decide whether a page will be accessed as a
JSP or as an Action and design for the one scenario. The simplest (and
safest) design rule will be to access all pages through either one
mechanism or the other.

Comments?

Sid Stuart








--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Design question about ActionForm's validate method

[Robert Nocera]

Direct the user to an action that isn't the action associated with the
page in question, even if all that action does is forward to the JSP
page.  Generally the action's associated with a JSP page get called from
that JSP page.

ActionA forwards to B.JSP, B.JSP submits to ActionB and so on...

Alternately provide a hidden form variable in your page, in your
validation method, check for it, if it's not there, don't continue
validating as the user did not just submit the page.

Robert Nocera
New England Open Solutions
www.neosllc.com
"You supply the vision, we'll do the rest."
 

-Original Message-
From: Sid Stuart [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, February 05, 2002 12:25 PM
To: Struts Users Mailing List
Subject: Design question about ActionForm's validate method

Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the validate method is
called before the user ever sees the page, much less inputs valid data
to the form. This leads to an unfortunate display of unwarranted error
messages.

It would be nice if the documentation would provide a rule such as:
If one plans on the user calling the Action directly in the URL  then
one should not use the automatic validation provided by ActionForm.

Further, as having two different procedures to generate a page can lead
to subtle errors, one should decide whether a page will be accessed as a
JSP or as an Action and design for the one scenario. The simplest (and
safest) design rule will be to access all pages through either one
mechanism or the other.

Comments?

Sid Stuart




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Design question about ActionForm's validate method

[Sid Stuart]

Hi,

I've stumbled across a subtle problem/design question that I don't see
mentioned in the documentation.

The ActionForm's validate method can be configured to verify form data
from a page and generate error messages which may then be displayed on
the page for the user to see. This works fine when the user has accessed
the page by specifying a JSP file in the URL. When the user accesses the
page by calling the Action directly though, the validate method is
called before the user ever sees the page, much less inputs valid data
to the form. This leads to an unfortunate display of unwarranted error
messages.

It would be nice if the documentation would provide a rule such as:
If one plans on the user calling the Action directly in the URL  then
one should not use the automatic validation provided by ActionForm.

Further, as having two different procedures to generate a page can lead
to subtle errors, one should decide whether a page will be accessed as a
JSP or as an Action and design for the one scenario. The simplest (and
safest) design rule will be to access all pages through either one
mechanism or the other.

Comments?

Sid Stuart

Design question - output Action

[Carl Hope]

I'm fairly new to Struts and have just built my first mini-project.  I have
a basic question that I couldn't find addressed in the mail archives.

I think I understand the "input" half of a user interaction - when
information is input by the user, it is handled on the server via the
ActionServlet which delegates to the associated  FormBean and Action.  The
Action invokes the business logic to process the data and update the model.
If there is an error, then control is forwarded to the JSP page which uses
the FormBean to repopulate the input fields and can also display the errors.

My question concerns the "output" side when there is no error.  The JSP
displays information using tags and standard JSP features.  If there is a
complex logic required to create the information for the JSP, where should
that logic be placed and invoked?  Obviously business logic should be placed
in model beans, but what about the component that invokes the various bean
methods?  This is the equivalent of the Action on the "input" side.  Also,
what role if any should the FormBean play?   This logic should not be in the
input Action because the JSP could be called from multiple Actions.

Sorry to be so long-winded, but I'm trying to make sure I understand the
framework before building larger apps.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Design question on loading form data

[Nick Thomson]

In keeping with MVC there should not be any business loic in the form bean.
Therefore the action class should be responsible for populating your form
bean.  Also, the main purpose of reset() in the form bean is to clear the
form's fields before the post() method populates it with the user's input.
Reset() is invoked automatically by struts. Specifically you cannot detect
changes to checkboxes unless they are reset first.
- Original Message -
From: "Mattias Norlander" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 19, 2002 8:52 AM
Subject: Design question on loading form data


> Hello!
>
> If i want to fill a form with data (from, say a database) before showing
> it to the user: Can this be done in reset() method of the form, or should
> it be in the perform() method of the action class?
>
> I think that doing it in the reset() method produces the cleanest code.
> This can be done in quite a dynamic way too, since the reset method has
> access to the http request and the mapping. It can use these to get info
> on what (if any) item to load from the database.
>
> Short example:
>
> <--->
> I have an action called editOrder and a form called orderForm.
> In the reset method of the form:
>
> reset(mapping,request) {
>
>   // check mapping, the form might be used by other actions
>   // that don't want our little featue
>   if (mapping.getType.equals("editOrder") {
>  int orderId = request.getInt("orderId");
>  OrderData order = db.loadOrder(orderId);
>  this.orderName = order.getName();
>  this.orderSize = order.getSize();
>  // .. and so on
>
>   }
>
> }
> <--->
>
> Any suggestions or thoughts around this way of doing things? Looks nice to
> me,
> but I'd sure like to know if there is something nasty that I've missed
here.
>
> Regards,
>
> Mattias Norlander
>
>
> --
> 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]>

Re: Design question on loading form data

[Keith Bacon]

Hi Mattias,
The form bean is designed for easing the coding for moving of data from action
class to HTML form & vice versa. 
Has any-one got a good case for doing anything else?
Keith.


--- Struts Newsgroup <[EMAIL PROTECTED]> wrote:
> Subject: Re: Design question on loading form data
> From: Vic Cekvenich <[EMAIL PROTECTED]>
>  ===
> Here is sample pseudo code illustrating for one approach in 
> action/perform. Call for the model bean to populate in the action's 
> perform. Maybe the code of that retrieval and anything else having to do 
> with data is in the model bean. I sometimes use the FormBean, with 
> getters and setters, and put a retrieve, update, insert, delete methods 
> in the bean, so model is in one place, should there be any bugs.
> Also, you can create such a bean, and test it in just a normal servlet, 
> before putting it in Struts. You could also test or use that bean anyplace.
> 
> 
> 
> package app;
> public class NameLstAct extends baseAct {
> public ActionForward mperform( ActionMapping mapping,
>   ActionForm form,HttpServletRequest request,
>   HttpServletResponse response)
>   throws IOException, ServletException {
> // if list
> sf=(SearchFrm)session.getAttribute("SearchFrm"); // get the arguments
> String fn= sf.getFstName();
> String ln= sf.getLstName();
> NameLstFrm nl = new NameLstFrm(); // make the Form Bean
> 
>   nl.dbCon(); // ask bean to get a connection from the pool
> 
>   // get us a list of names; based on retrieval argments
>   nl.retrieve(fn,ln);
>   //obviously, the FormBean has the SQL command coded in the above method
> 
>   nl.dbDisCon(); // we do not need the connection no more
> 
> return(mapping.findForward("nameLstPg"));
> 
> // if save
> // {nl.validate(); nl.update(); ... }
> // if delete {nl.delete(); ...}
> // if new/insert {nl.inset(); ...}
> }// perform Act
> } // end of code.
> 
> 
> 
> 
> Mattias Norlander wrote:
> 
> > Hello!
> > 
> > If i want to fill a form with data (from, say a database) before showing
> > it to the user: Can this be done in reset() method of the form, or should
> > it be in the perform() method of the action class?
> > 
> > I think that doing it in the reset() method produces the cleanest code.
> > This can be done in quite a dynamic way too, since the reset method has
> > access to the http request and the mapping. It can use these to get info
> > on what (if any) item to load from the database.
> > 
> > Short example:
> > 
> > <--->
> > I have an action called editOrder and a form called orderForm.
> > In the reset method of the form:
> > 
> > reset(mapping,request) {
> > 
> >   // check mapping, the form might be used by other actions
> >   // that don't want our little featue
> >   if (mapping.getType.equals("editOrder") {
> >  int orderId = request.getInt("orderId");
> >  OrderData order = db.loadOrder(orderId);
> >  this.orderName = order.getName();
> >  this.orderSize = order.getSize();
> >  // .. and so on
> > 
> >   }
> > 
> > }
> > <--->
> > 
> > Any suggestions or thoughts around this way of doing things? Looks nice to
> > me,
> > but I'd sure like to know if there is something nasty that I've missed here.
> > 
> > Regards,
> > 
> > Mattias Norlander
> > 
> > 
> > --
> > 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]>
> 


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Design question on loading form data

[@Basebeans.com]

Subject: Re: Design question on loading form data
From: Vic Cekvenich <[EMAIL PROTECTED]>
 ===
Here is sample pseudo code illustrating for one approach in 
action/perform. Call for the model bean to populate in the action's 
perform. Maybe the code of that retrieval and anything else having to do 
with data is in the model bean. I sometimes use the FormBean, with 
getters and setters, and put a retrieve, update, insert, delete methods 
in the bean, so model is in one place, should there be any bugs.
Also, you can create such a bean, and test it in just a normal servlet, 
before putting it in Struts. You could also test or use that bean anyplace.



package app;
public class NameLstAct extends baseAct {
public ActionForward mperform( ActionMapping mapping,
ActionForm form,HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// if list
sf=(SearchFrm)session.getAttribute("SearchFrm"); // get the arguments
String fn= sf.getFstName();
String ln= sf.getLstName();
NameLstFrm nl = new NameLstFrm(); // make the Form Bean

  nl.dbCon(); // ask bean to get a connection from the pool

  // get us a list of names; based on retrieval argments
  nl.retrieve(fn,ln);
  //obviously, the FormBean has the SQL command coded in the above method

  nl.dbDisCon(); // we do not need the connection no more

return(mapping.findForward("nameLstPg"));

// if save
// {nl.validate(); nl.update(); ... }
// if delete {nl.delete(); ...}
// if new/insert {nl.inset(); ...}
}// perform Act
} // end of code.




Mattias Norlander wrote:

> Hello!
> 
> If i want to fill a form with data (from, say a database) before showing
> it to the user: Can this be done in reset() method of the form, or should
> it be in the perform() method of the action class?
> 
> I think that doing it in the reset() method produces the cleanest code.
> This can be done in quite a dynamic way too, since the reset method has
> access to the http request and the mapping. It can use these to get info
> on what (if any) item to load from the database.
> 
> Short example:
> 
> <--->
> I have an action called editOrder and a form called orderForm.
> In the reset method of the form:
> 
> reset(mapping,request) {
> 
>   // check mapping, the form might be used by other actions
>   // that don't want our little featue
>   if (mapping.getType.equals("editOrder") {
>  int orderId = request.getInt("orderId");
>  OrderData order = db.loadOrder(orderId);
>  this.orderName = order.getName();
>  this.orderSize = order.getSize();
>  // .. and so on
> 
>   }
> 
> }
> <--->
> 
> Any suggestions or thoughts around this way of doing things? Looks nice to
> me,
> but I'd sure like to know if there is something nasty that I've missed here.
> 
> Regards,
> 
> Mattias Norlander
> 
> 
> --
> 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]>

Re: Design question on loading form data

[Jorge Ruiz \(SX\)]

I think this should be in the perform() method. If you look at the javadocs,
reset() is called before populating the form fields with the values received
from the HTTP request. This way you can assign default values for fields
that may be missing from the HTTP request.

This is different from the reset() action in the browser's form. When you do
a reset in an HTML form the browser just reloads whatever values were there
originally and does not perform an HTTP request. The fact that both methods
refer to forms but in different contexts is missleading eh?

Cheers,

Jorge
- Original Message -
From: "Mattias Norlander" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 19, 2002 9:52 AM
Subject: Design question on loading form data


> Hello!
>
> If i want to fill a form with data (from, say a database) before showing
> it to the user: Can this be done in reset() method of the form, or should
> it be in the perform() method of the action class?
>
> I think that doing it in the reset() method produces the cleanest code.
> This can be done in quite a dynamic way too, since the reset method has
> access to the http request and the mapping. It can use these to get info
> on what (if any) item to load from the database.
>
> Short example:
>
> <--->
> I have an action called editOrder and a form called orderForm.
> In the reset method of the form:
>
> reset(mapping,request) {
>
>   // check mapping, the form might be used by other actions
>   // that don't want our little featue
>   if (mapping.getType.equals("editOrder") {
>  int orderId = request.getInt("orderId");
>  OrderData order = db.loadOrder(orderId);
>  this.orderName = order.getName();
>  this.orderSize = order.getSize();
>  // .. and so on
>
>   }
>
> }
> <--->
>
> Any suggestions or thoughts around this way of doing things? Looks nice to
> me,
> but I'd sure like to know if there is something nasty that I've missed
here.
>
> Regards,
>
> Mattias Norlander
>
>
> --
> 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]>

Design question on loading form data

[Mattias Norlander]

Hello!

If i want to fill a form with data (from, say a database) before showing
it to the user: Can this be done in reset() method of the form, or should
it be in the perform() method of the action class?

I think that doing it in the reset() method produces the cleanest code.
This can be done in quite a dynamic way too, since the reset method has
access to the http request and the mapping. It can use these to get info
on what (if any) item to load from the database.

Short example:

<--->
I have an action called editOrder and a form called orderForm.
In the reset method of the form:

reset(mapping,request) {

  // check mapping, the form might be used by other actions
  // that don't want our little featue
  if (mapping.getType.equals("editOrder") {
 int orderId = request.getInt("orderId");
 OrderData order = db.loadOrder(orderId);
 this.orderName = order.getName();
 this.orderSize = order.getSize();
 // .. and so on

  }

}
<--->

Any suggestions or thoughts around this way of doing things? Looks nice to
me,
but I'd sure like to know if there is something nasty that I've missed here.

Regards,

Mattias Norlander


--
To unsubscribe, e-mail:   
For additional commands, e-mail: