RE: HTML tags - WHY?

[Robert Scaduto]

Internationalization is one of the main reasons I see in using the Struts
tags for non-form related tags.  Our site is implemented in several
languages and so all of the images and text come from ResourceBundles.
Struts is automatically aware of these bundles and will display the right
content for the specified locale. The  tag is a good example of
this.

Outside of this the  tag will automatically handle URL rewriting
of the jsessionid for users who do not support cookies.

I think if you took some time and examined the inner workings of all of the
html tags you would find that even though you may have no use for some of
the features they implement, each of them adds something that may be of
value for someone.  The nice part about it is you don't have to use them if
you don't want to.

-Robert Scaduto

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 5:21 PM
To: Struts Users Mailing List
Subject: Re: HTML tags - WHY?



Maybe I should rephrase the question.  I understand what the tags are for
when related to form items and even hyperlinks (allowing forwards), but
what is the point of duplicating the others?

- Cody





Jim Crossley <[EMAIL PROTECTED]>@jimmy.ifleet.com on 02/07/2002 04:14:45
PM

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

Sent by:  [EMAIL PROTECTED]

To:   Struts Users Mailing List <[EMAIL PROTECTED]>
cc:
Subject:  Re: HTML tags - WHY?


That is certainly the biggie.  Coupla others:

- Transparently inserts context path prefix.
- Automatically encodes html-specific characters

"Krueger, Jeff" <[EMAIL PROTECTED]> writes:

> One thing is it will populate the tag with the value from your formBean.
>
> Jeff
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 07, 2002 3:00 PM
> To: Struts Users Mailing List
> Subject: HTML tags - WHY?
>
>
>
>
> Can someone help me understand why struts duplicates almost all standard
> HTML tags. In all of these cases, struts adds something special that is
not
> already inherent in the tag?
>
> - Cody
>
> 
> 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]>
>
> --
> 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]>





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


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

RE: How to name, package Actions

[Robert Scaduto]

In response to your first question, in my experience I try to name action
classes after what they actually do vs. what calls them.  I have done this
because in several instances I have been able to re-use actions in different
parts of the web site using different action mappings.  By naming it
specifically for scenario A it might be confusing or misleading in scenario
B.

To exemplify the two actions you presented, I would name them...

action1:  ConfirmDeleteWidgetAction
action2:  DeleteWidgetAction

This way if you wanted to delete the widget somewhere else in your web app
without the confirm check, the mapping would make sense at first glance. I
you wanted to get real smart you could even develop a ConfirmAction base
class to handle the semantics of confirming another action :)

In response to question 2.  It all depends. There is always a delicate
balance between too much packaging and not enough. It depends on your app.
For example if you have an app with 4-5 actions you might just want to put
the actions and the forms in one package.  If you had an app with 10-15
actions you might want to split up the actions and the forms in to separate
packages.  For apps with still more actions you might do it based on use
cases like you mentioned in your OPTION 2. I'm a firm believer in planning
on unplanned growth so I think OPTION 2 is probably the most flexible and
self-documenting.

Just my 2 cents.

-Robert Scaduto

-Original Message-
From: Molitor, Stephen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 4:19 PM
To: 'Struts Users Mailing List'
Subject: How to name, package Actions


I have two best-practices questions:

FIRST QUESTION:  How best to name Action classes?  Do you name an action
after the button that initiates it, the place it comes from?  Or, do you
name the action for what it goes to?  Or, for what the action does -- but
sometimes it's not so simple.  For example, imagine this scenario:

1.  From the 'Show Widget' page, user selects the 'Delete Widget' button.
2.  action1 is performed, which forwards to the 'Are You Sure?' page.
4.  User selects 'yes'
5.  action2 is performed, which physically deletes the record.

What are good names for action1 and action2?  If you name your actions for
the user gestures that trigger them, you might have this:

action1:  DeleteWidgetAction
action2:  YesReallyDeleteTheWidgetAction

Naming the first action 'DeleteWidgetAction' seems to make sense, since its
triggered by clicking on the 'Delete Widget' button.  But, then it's hard to
come up with a name for action2.  Plus, action1's name is misleading,
because it doesn't actually perform the delete.  OK, lets try naming the
actions after what they really do:

action1:  ConfirmDeleteWidgetAction
action2:  DeleteWidgetAction

This seems a bit better, but action1's name is a bit awkward.

In one way, Actions are like events triggered by clicking on something.  In
another sense, Actions represent the transition between two states, the
previous and next pages.  Or, they're just reusable commands.  This last
view is probably the most accurate, but I find it hard to come up with names
for commands.  Any heuristices or guidelines for naming actions would be
appreciated.


SECOND QUESTION:
How best to package Actions and ActionForms?  It's no problem for small
apps, but becomes a problem for larger ones.  Do you have lots of small
packages?  Do you put ActionForms and Actions in the same package?   Or,
separate sub-packages for Actions and ActionForms?

Lets say I working for an application called 'MyApp', for a company called
'Acme', and that there's a set of pages in the app dealing with user
registration.  Here are some packaging options:

OPTION 1 - By app --> sub-app
com.acme.myapp.registration.Form1
com.acme.myapp.registration.Form2
com.acme.myapp.registration.Action1
com.acme.myapp.registration.Action2

OPTION 2 - By app --> sub-app --> object type
com.acme.myapp.registration.forms.Form1
com.acme.myapp.registration.forms.Form2
com.acme.myapp.registration.actions.Action1
com.acme.myapp.registration.actions.Action2

OPTION 3 - By app --> object type --> sub-app
com.acme.myapp.forms.registration.Form1
com.acme.myapp.forms.registration.Form2
com.acme.myapp.actions.registration.Action1
com.acme.myapp.actions.registration.Action2

(I don't care for option 3.)

Any thoughts, other schemes?  I presume one would a matching sub-directory
structure for the JSP's.


Thanks!

Steve Molitor
[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: Implementing HTTPS in Struts

[Robert Scaduto]

Thanks, Max,

In the mean time as a work around I will just mark the action called before
any secure data is posted is also secure, ensuring that the data is sent
encrypted.

Thanks Again,

Rob

-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 7:04 PM
To: Struts Users Mailing List
Subject: Re: Implementing HTTPS in Struts


Rob,

You are absolutely correct that that is an issue. Our proposed solution for
it is to modify (or extend until this functionality is integrated into
Struts) the Struts form tag as you suggest, so that it will compute the
right URL, which may be an absolute https URL if the target action is
secure.

The primary mechanism for doing the HTTP/HTTPS switching is the extended
tags that compute the proper URL. The redirecting stuff is secondary and
only there in the case that someone makes an errant request (by typing the
URL, bad bookmark, etc.).

-Max

- Original Message -
From: "Robert Scaduto" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 2:22 PM
Subject: RE: Implementing HTTPS in Struts


> Steve,
>
> Thank you for your response.  I have taken a look at your https framework
> and I it looks great. I do have one concern though.
>
> In looking through the code I noticed that if a non-secure request comes
in
> to a action marked as secure, the framework will persist the request
> attributes in the session and tell the browser to re-direct using https.
> However this allows the parameters in the form or querystring to go across
> the network un-encrypted before the framework can perform the redirect.
>
> My thought was that the same SecureRequestUtils.computeURL() function
should
> also be used by the form tag to determine, before the form is rendered,
that
> the post should be transmitted via https.  This would require subclassing
> the struts FormTag as well.
>
> Am I totally off base here?
>
> -Rob
>
> -Original Message-
> From: Ditlinger, Steve [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 7:30 PM
> To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Implementing HTTPS in Struts
>
>
>
> Robert:
>
> We recently posted just such a solution.  Check it out at
> http://struts.ditlinger.com.  There you will find a description of our
> solution and a link to download our Struts extensions and example app.  If
> you have any questions, please do not hesitate to ask.
>
> Steve
>
>
> >You wrote:
> ---
> Hello all, my name is Rob Scaduto and I have just recently joined the
Struts
> user mailing list. I have yet to find any resources talking about how to
> handle switching between http and https (and vice versa) using struts. The
> only solution I was able to come up with was sub classing the Struts
LinkTag
> and adding a secure attribute. This would then dynamically build an
absolute
> path based on the jsp. This works great when you use the forward or page
> attribute, but doesn't work at all if you use the href attribute. I'd like
> to have a solution that works in all cases and I was curious if someone
> could add some insight. Thanks in advance, Rob
>
>
> --
> 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: Implementing HTTPS in Struts

[Robert Scaduto]

Steve,

Thank you for your response.  I have taken a look at your https framework
and I it looks great. I do have one concern though.

In looking through the code I noticed that if a non-secure request comes in
to a action marked as secure, the framework will persist the request
attributes in the session and tell the browser to re-direct using https.
However this allows the parameters in the form or querystring to go across
the network un-encrypted before the framework can perform the redirect.

My thought was that the same SecureRequestUtils.computeURL() function should
also be used by the form tag to determine, before the form is rendered, that
the post should be transmitted via https.  This would require subclassing
the struts FormTag as well.

Am I totally off base here?

-Rob

-Original Message-
From: Ditlinger, Steve [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 7:30 PM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: Re: Implementing HTTPS in Struts



Robert:

We recently posted just such a solution.  Check it out at
http://struts.ditlinger.com.  There you will find a description of our
solution and a link to download our Struts extensions and example app.  If
you have any questions, please do not hesitate to ask.

Steve


>You wrote:
---
Hello all, my name is Rob Scaduto and I have just recently joined the Struts
user mailing list. I have yet to find any resources talking about how to
handle switching between http and https (and vice versa) using struts. The
only solution I was able to come up with was sub classing the Struts LinkTag
and adding a secure attribute. This would then dynamically build an absolute
path based on the jsp. This works great when you use the forward or page
attribute, but doesn't work at all if you use the href attribute. I'd like
to have a solution that works in all cases and I was curious if someone
could add some insight. Thanks in advance, Rob


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: How can I get Struts to re-read the config file?

[Robert Scaduto]

Struts includes a ReloadAction that will reload the struts-config.xml and
the ApplicationResources.

Just include...



in your struts config.   To re-load, navigate your browser to
/admin/reload.do

That should do it.

-Rob


-Original Message-
From: Press, Michael [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 2:33 PM
To: '[EMAIL PROTECTED]'
Subject: How can I get Struts to re-read the config file?


I would like for my webapp to be able to re-read struts-config.xml without
having to bounce the servlet container (Tomcat 4.0.1) or bounce/reload my
webapp.  Is this possible?

Thanks,
Michael

--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: Database Servlet

[Robert Scaduto]

You could keep a reference to the last modified date of the xml file when
you init the servlet and then check the timestamp every time your main page
runs.  If it changes the re-run the digester.

-or-

If you don't have access to the timestamp then, you could refresh at
periodic intervals on a different thread. And then replace the old java
beans in the ServletContext.

-or-

You can read the file every time if the page needs to be in sync at all
times. This is the most accurate solution but not the most efficient.

Hope this helps,

Rob

-Original Message-
From: Konstantina Stamopoulou [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 7:43 AM
To: Struts Users Mailing List
Subject: Database Servlet


Hello,

I apologize if my question sounds naive but I really need your help on this.
 I have a servlet that during initialization parses an .xml file using
Digester. Then I access the data in  my jsps through JavaBeans. What I need
to do, is to have my main page which displays the data from the .xml to be
updated with the new data each time the .xml is modified.
In order to do this, do I have to put the code of the init() method of my
servlet in the Action class of the main page or is it a more elegant way to
do this?

Thank you  in advance,
Konstantina


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

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 information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy t

RE: error display

[Robert Scaduto]

You need to use the  tag.  This will display all of the errors
that you returned from the validate function of your action form.



-Original Message-
From: Henry Lu [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 7:30 AM
To: Struts Users Mailing List
Subject: error display


WHen there is error in the validate() function, my jsp page only displays


Why? How to let the page display the message specified in the validate()
function?


---
Henry Lu
MCITphone: (734) 936-2063
University of Michigan Medical Center   fax:   (734) 763-4372



--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: form validation failure and state

[Robert Scaduto]

The collections that are used in the drop-down's.  Where are they created?
If they are created in your init method and stored in request scope. Then
they won't be there for the form unless they are created again when the
validation fails.  You can store these collections in application scope so
that they will always be available to the options tag.  Another solution
would be to make the input attribute in your action mapping the action that
creates the collections.

-Original Message-
From: Jon Burford [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 5:48 PM
To: [EMAIL PROTECTED]
Subject: form validation failure and state


I've got a form with text fields and drop down list boxes which is fully
populated by an init action before the form is displayed.  The user can then
make changes and submit the form, which in turn calls the validate function
on my form object.  If I detect invalid input, I return one or more errors
from my validate function and the errors are displayed by struts along with
the form they were changing.  The problem I am having is that struts seems
to remember and populate all the text fields correctly when it redisplays
the form with the errors, but the drop downs are empty.  I know of a couple
ways I could repopulate the drop downs, but I was wondering why struts
remembers what's in the text fields, but not in the drop downs?  Am I
missing something, or is this how it works?


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: form validation failure and state

[Robert Scaduto]

In my experience, struts will repopulate all fields including any drop-down
menus but only if they are implemented using the  tag.  If you
are generating the drop-downs without the help of the struts taglib then it
cannot repopulate the form.

A) Are you using the struts tags for the drop-downs?
B) If so does the validate function wipe out the values that would be
displayed by the drop down?

-Original Message-
From: Jon Burford [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 5:48 PM
To: [EMAIL PROTECTED]
Subject: form validation failure and state


I've got a form with text fields and drop down list boxes which is fully
populated by an init action before the form is displayed.  The user can then
make changes and submit the form, which in turn calls the validate function
on my form object.  If I detect invalid input, I return one or more errors
from my validate function and the errors are displayed by struts along with
the form they were changing.  The problem I am having is that struts seems
to remember and populate all the text fields correctly when it redisplays
the form with the errors, but the drop downs are empty.  I know of a couple
ways I could repopulate the drop downs, but I was wondering why struts
remembers what's in the text fields, but not in the drop downs?  Am I
missing something, or is this how it works?


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Implementing HTTPS in Struts

[Robert Scaduto]

Hello all, my name is Rob Scaduto and I have just recently joined the Struts
user mailing list.

I have yet to find any resources talking about how to handle switching
between http and https (and vice versa) using struts.  The only solution I
was able to come up with was sub classing the Struts LinkTag and adding a
secure attribute.

This would then dynamically build an absolute path based on the jsp.  This
works great when you use the forward or page attribute, but doesn't work at
all if you use the href attribute.

I'd like to have a solution that works in all cases and I was curious if
someone could add some insight.

Thanks in advance,

Rob


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