About Datasource

[Kalaiselvan]

Hii All,

Any one know how to get multiple Datasource from Struts.
Because i think in Struts-config.xml, we are able to specify only one
Datasource.

Also I got an error when I configure my datasources in tomcat's
sever.xml  I couldnt able to get that datasource name in
my Strtus's application.But my ordinary application can able to ge the
Datasources from server.xml. Why this is happend???

Thanx in Advance

Kalaiselvna.S




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

RE: Help Re: cancel and session-scope form

[Tal Lev-Ami]

You can add another action without a form-bean that will implement the
cancel functionality and in all other cases forward the request to your real
action where the ActionForm will be populated.

Tal Lev-Ami
Trivnet Ltd.

-Original Message-
From: Angie Lin [mailto:[EMAIL PROTECTED]]
Sent: Sun, September 29, 2002 10:26 PM
To: Struts Users Mailing List
Subject: Re: Help Re: cancel and session-scope form


Thanks for the tip, but I'm trying to avoid javascript as much as 
possible.  It looks like I'll have to go ahead and manage my session 
form manually, and use a request-scoped form so that the auto-population 
doesn't blow away the properties.  

Thanks again,
Angie

Eddie Bush wrote:

> Actually ... I've never done this before, but ...
>
> Why couldn't you invoke a javascript method on your Cancel button that 
> invoked the forms reset method?  That might be the easiest solution ...
>
> Eddie Bush wrote:
>
>> Just quickly thinking it over ...
>>
>> When your form submits, you're going to hit an action.  Your action 
>> is going to look and see what the user told you they wanted to do and 
>> act appropriately.  Now, that doesn't help you keep the form from 
>> being populated, but you can certainly keep from updating your 
>> persistent storage using this information - and know that, instead, 
>> you should request fresh data to repopulate the form with.  I like to 
>> rename my buttons to something like "action" or "userAction" - and 
>> give all of them the same name - so I can judge off the value of that 
>> parameter what the user is telling me they'd like to have happen.
>>
>> That's my "spontaneous, first-cut" answer.  I can't think of a way to 
>> circumvent the population ... 
>
>
>

-- 
Angie Lin
[EMAIL PROTECTED]
408.519.9250



--
To unsubscribe, e-mail:

For additional commands, e-mail:


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

RE: Pre-populating ActionForms

[Mohan Radhakrishnan]

Hi,
 I have actually set up a 'Setup' form and action. After login, I
forward to setup.jsp, that doesn't show anything(though is is a jsp) but
pre-populates the form. How do you forward from there to the JSP that shows
the pre-populated form ? There is no submit action on setup.jsp.
bye,
Mohan

-Original Message-
From: David Graff [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 28, 2002 9:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Pre-populating ActionForms


Override the 'reset' method of the ActionForm descendant, set your initial
values in there, then (most likely) when you want to reference the page,
reference the .do that would forward you out to that page.

Hope that helps.



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

Security bug in the sample application?

[Cuneyt Karul]

Hi,

I was playing with the sample application that comes with struts and I noticed a 
strange behavior. I just wanted to check out if this is expected, and if so what is 
the best way to solve this problem.

When I log on with a valid user the application takes me to the page:
http://localhost:8080/struts-example/logon.do

Here I choose the Log off MailReader Demonstration Application link which logs me off 
from the application.

Then I use BACK button of my browser to go to the logon.do page and reload this page.
I expect the application to send me back to the logon page (and it does so for all the 
other pages).

On the browser I get a message like "this page can not be refreshed without resending 
the information".
I hit retry and volla I'm logged back to the application without even being prompted 
for username and password.

I modified the code to trace this in server logs and noticed that both username and 
the password are actually kept in the memory and sent back to the server.

Is there a nice way to prevent this behavior?

Thanks

Cuneyt Karul

RE: [Contributing] Re: all this traffic

[Hookom, Jacob John]

I agree, from observing what others are developing, it seems that about 80% of the 
applications are for intranets.  I know even our campus is using struts for various 
project management applications.  Could we offer links to the sites? No.  Is the 
presentation layer what counts? No.
 
What would be advantagous is a case study page-- how struts helped us do what we 
needed in a timely manner.  I believe that would be much more practical than a bunch 
of links to web sites to check out the pretty graphics.
 
I remember reading a great article in Java Developer about Cocoon a little while back, 
the guy went on for nearly 2 pages on how he was able to use cocoon to help a law firm 
manage documents.  Something like that is 10 fold more beneficial than having the 
author just post a link to the site he did.
 
Regards
Jacob Hookom
University of Wisconsin, Eau Claire

-Original Message- 
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
Sent: Sun 9/29/2002 8:29 PM 
To: Struts Users Mailing List 
Cc: 
Subject: RE: [Contributing] Re: all this traffic





On Sun, 29 Sep 2002, Khan, Manuchehar A (ACF) wrote:

> Date: Sun, 29 Sep 2002 21:14:50 -0400
> From: "Khan, Manuchehar A (ACF)" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: [Contributing] Re: all this traffic
>
> This is for Craig. I believe you are at home today.  Can we do a better job
> of listing companies that are in process of developing applications in
> struts or already have applications in production. This helpes in convincing
> managements to take a
> more closer look at sturt.
> Thanks
>

Well, this certainly sounds like an opportunity for you to submit a patch
that improves the website (which is just the struts-documentation web app
:-).  Companies that want to be listed can do so, if they obey the
requirements about advertising the fact that they use Struts and/or Apache
Software Foundation software packages.

Of course, none of this helps if the companies using Struts cannot be
listed (because the usage is on internal company webapps), or don't *want*
to be listed (because they consider their choice of Struts to be a
strategic advantage that they don't want their competitors to know about
:-).

As with code changes, patches to the resources pages (including the
"Powered by Struts" page) are welcome.

Craig


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 29, 2002 9:05 PM
> To: Struts Users Mailing List
> Subject: Re: [Contributing] Re: all this traffic
>
>
>
>
> On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote:
>
> > >
> > >   http://jakarta.apache.org/site/getinvolved.html
> > >
> >
> > What is the format of the patches that developers /contributer patches
> submit?
> > Is it a context difference?
> >
> > diff -c  acme.java  acme.java.orig
> >
>
> The specific instructions on submitting patches are on the following page:
>
>   http://jakarta.apache.org/site/bugs.html
>
> which is accessible from the page I quoted above.  You need to use the
> *unified* diff format, via one of the following commands:
>
>   cvs diff -u acme.java >> patchfile.txt
>
>   diff -u acme.java.orig acme.java >> patchfile.txt
>
> and then add the patchfile as an attachment to an enhancement request (or
> bug report) in the bug tracking system.  The "cvs diff" version is
> preferred, because it unambiguously identifies the version of the source
> file that your patch is against -- if you use the regular "diff" command,
> please be explicit about which version of the source you are patching.
>
>
> > --
> > Peter Pilgrim
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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




<>
--
To unsubscribe, e-mail:   
For additi

RE: [Contributing] Re: all this traffic

[Craig R. McClanahan]

On Sun, 29 Sep 2002, Khan, Manuchehar A (ACF) wrote:

> Date: Sun, 29 Sep 2002 21:14:50 -0400
> From: "Khan, Manuchehar A (ACF)" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: [Contributing] Re: all this traffic
>
> This is for Craig. I believe you are at home today.  Can we do a better job
> of listing companies that are in process of developing applications in
> struts or already have applications in production. This helpes in convincing
> managements to take a
> more closer look at sturt.
> Thanks
>

Well, this certainly sounds like an opportunity for you to submit a patch
that improves the website (which is just the struts-documentation web app
:-).  Companies that want to be listed can do so, if they obey the
requirements about advertising the fact that they use Struts and/or Apache
Software Foundation software packages.

Of course, none of this helps if the companies using Struts cannot be
listed (because the usage is on internal company webapps), or don't *want*
to be listed (because they consider their choice of Struts to be a
strategic advantage that they don't want their competitors to know about
:-).

As with code changes, patches to the resources pages (including the
"Powered by Struts" page) are welcome.

Craig


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 29, 2002 9:05 PM
> To: Struts Users Mailing List
> Subject: Re: [Contributing] Re: all this traffic
>
>
>
>
> On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote:
>
> > >
> > >   http://jakarta.apache.org/site/getinvolved.html
> > >
> >
> > What is the format of the patches that developers /contributer patches
> submit?
> > Is it a context difference?
> >
> > diff -c  acme.java  acme.java.orig
> >
>
> The specific instructions on submitting patches are on the following page:
>
>   http://jakarta.apache.org/site/bugs.html
>
> which is accessible from the page I quoted above.  You need to use the
> *unified* diff format, via one of the following commands:
>
>   cvs diff -u acme.java >> patchfile.txt
>
>   diff -u acme.java.orig acme.java >> patchfile.txt
>
> and then add the patchfile as an attachment to an enhancement request (or
> bug report) in the bug tracking system.  The "cvs diff" version is
> preferred, because it unambiguously identifies the version of the source
> file that your patch is against -- if you use the regular "diff" command,
> please be explicit about which version of the source you are patching.
>
>
> > --
> > Peter Pilgrim
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

RE: [Contributing] Re: all this traffic

[Khan, Manuchehar A (ACF)]

This is for Craig. I believe you are at home today.  Can we do a better job
of listing companies that are in process of developing applications in
struts or already have applications in production. This helpes in convincing
managements to take a  
more closer look at sturt. 
Thanks 

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 9:05 PM
To: Struts Users Mailing List
Subject: Re: [Contributing] Re: all this traffic




On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote:

> >
> >   http://jakarta.apache.org/site/getinvolved.html
> >
>
> What is the format of the patches that developers /contributer patches
submit?
> Is it a context difference?
>
> diff -c  acme.java  acme.java.orig
>

The specific instructions on submitting patches are on the following page:

  http://jakarta.apache.org/site/bugs.html

which is accessible from the page I quoted above.  You need to use the
*unified* diff format, via one of the following commands:

  cvs diff -u acme.java >> patchfile.txt

  diff -u acme.java.orig acme.java >> patchfile.txt

and then add the patchfile as an attachment to an enhancement request (or
bug report) in the bug tracking system.  The "cvs diff" version is
preferred, because it unambiguously identifies the version of the source
file that your patch is against -- if you use the regular "diff" command,
please be explicit about which version of the source you are patching.


> --
> Peter Pilgrim

Craig


--
To unsubscribe, e-mail:

For additional commands, e-mail:


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

Re: [Contributing] Re: all this traffic

[Craig R. McClanahan]

On Mon, 30 Sep 2002, Peter A. J. Pilgrim wrote:

> >
> >   http://jakarta.apache.org/site/getinvolved.html
> >
>
> What is the format of the patches that developers /contributer patches submit?
> Is it a context difference?
>
> diff -c  acme.java  acme.java.orig
>

The specific instructions on submitting patches are on the following page:

  http://jakarta.apache.org/site/bugs.html

which is accessible from the page I quoted above.  You need to use the
*unified* diff format, via one of the following commands:

  cvs diff -u acme.java >> patchfile.txt

  diff -u acme.java.orig acme.java >> patchfile.txt

and then add the patchfile as an attachment to an enhancement request (or
bug report) in the bug tracking system.  The "cvs diff" version is
preferred, because it unambiguously identifies the version of the source
file that your patch is against -- if you use the regular "diff" command,
please be explicit about which version of the source you are patching.


> --
> Peter Pilgrim

Craig


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

[Contributing] Re: all this traffic

[Peter A. J. Pilgrim]

Craig R. McClanahan wrote:
> 
> On Fri, 27 Sep 2002, adam kramer wrote:
> 
> 
>>Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT)
>>From: adam kramer <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>Subject: RE: all this traffic
>>
>>
>>There's seems to be alot of resistance to any sort of suggestion that
>>might create better documentation and useability of Struts.
>>
> 
> 
> I can tell you for a fact that there's no resistance from Struts
> *developers* on this.  What we resist, however, is the implication that
> *we* should do all the work. :-)
> 
> Struts is an open source project.  The documentation is part of the source
> code, in easily accessible formats (for Struts, it is XML files that are
> post-processed to produce the HTML), and maintained in the same CVS
> archives that the code is.
> 
> Users are welcome to submit enhancement requests (for either the code or
> the documentation) via the bug tracking system:
> 
>   http://nagoya.apache.org/bugzilla/
> 
> and you can easily attach proposed patches to the enhancement requests.
> The general outline of how to create the patches starts at:
> 
>   http://jakarta.apache.org/site/getinvolved.html
> 

What is the format of the patches that developers /contributer patches submit?
Is it a context difference?

diff -c  acme.java  acme.java.orig

-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


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

Re: Retrieving list of Roles defined in web.xml [Revised]

[V. Cekvenich]

One alternative thing I have done that I consider simple is use 
container managed autherhication, and then call a getPricnciplal.
Based on the user name, I make a bean I put in session that contains all 
  kinds of information about the user, session, security. Things like 
full name, organization, roles, etc. etc.
These I them pass to beans for row based security.

It is cross app server, since it your own bean on top of the getPrinicpal().

hth,
V.

Craig R. McClanahan wrote:
> 
> On Fri, 27 Sep 2002, Vinh Tran wrote:
> 
> 
>>Date: Fri, 27 Sep 2002 08:54:31 -0400
>>From: Vinh Tran <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED]
>>To: [EMAIL PROTECTED]
>>Subject: Retrieving list of Roles defined in web.xml [Revised]
>>
>>I can also manage if there is a simple way to identify the roles a user
>>particpates in (using container managed security). There is a call for
>>isUserInRole() but nothing for getUserRoles()?
>>
> 
> 
> There is no getUserRoles() method available in the servlet API, which
> means that any answer you get is going to be application server dependent.
> Indeed, it is incorrect to assume that the list of roles a user has is
> static -- it's quite conceivable for your server to define a role as "is
> it between 8:00am and 5:00pm on a weekday" and use that to limit the times
> a particular application function is available.
> 
> You're going to need to research how your underlying app server stores and
> accesses authentication information.
> 
> 
>>Any ideas?
>>
>>Thanks.
> 
> 
> Craig




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

html:options

[Doug Dates]

I want to display a dropdown list. The list items are "By First Name", "By
Last Name", "By Date". I think I can do it by the following way:


 By First Name 
 By Last Name 
 By Date 


Is there any disadvantages to use above approach compared with using
? If I use  instead of using above
individual ,as following:


  


where should I set myArrayList? in init method of my servlet class, or in my
action form bean, or somewhere else? I am not quite understand it. Could
some one please help me?

Thank you

Doug



__ 
Post your free ad now! http://personals.yahoo.ca

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

Strange Behavior With Map$Entry

[Vinh Tran]

All:

After alot of experimenting I was able to finally figure out how to retrieve
a value from a Map.Entry.  However, it only works for certain tags.  Below
is an example of this behavior.






In the  tag the expressions do not work but in the  tag it
prints out the proper value.  Any ideas?

RE: logic:iterate with nested html:img

[Vinh Tran]

Eddie:

I figured out that EL is working fine and it does indeed work with all types
of tags.  Thanks again.

Vinh

-Original Message-
From: Vinh Tran [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 5:51 PM
To: Struts Users Mailing List
Subject: RE: logic:iterate with nested html:img


Eddie:

Thanks for you help.  I promise this will be the last response on this
thread.  I just want to be certain that it is valid to use EL with Struts
tags.  Meaning, by using the  tag I should be able to access
this object using EL.  Or do I have to use  or  in order
to use EL?

By the way, I have tried everything from  to
Anyway, thanks again and I will just have to continue
troubleshooting.

Vinh

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 12:33 AM
To: Struts Users Mailing List
Subject: Re: logic:iterate with nested html:img


Oh - cool!  Glad you could upgrade!

All you should have to do is drop the JAR you built into your app's lib
directory, copy the TLDs over into wherever you keep those, add
references to the taglibs in your web.xml, declare the taglib in your
page, and use them just like you would the Struts tags - BUT - you have
EL support.

If you're running Tomcat 4, why not install the JSTL and use that for
iteration?  :-)

I don't know what kind of errors you're getting in your page.  I think
things look like they are setup right.  One thing to remember is that
the EL is going to expect you to be following JavaBean patterns, so ...
is map.getSrcImage() valid?  is map.getDesc() valid?  If that's really a
map, you might want to try accessing it like map['srcImage'] and
map['desc'].

That's my best guess not knowing what problems you're having.

Vinh Tran wrote:

>Eddie:
>
>I'm finally up and running on Tomcat 4.0 but now I'm pulling my hair out
>trying to get EL to work.  Is it possible to use Struts-EL in conjunction
>with Struts tags?
>
>For example:
>scope="session" ignore="true"/>
>
>...later in the page I attempt to iterate through a collection...
>
>   
>
>
>Am I trying to defy the laws of physics, or at least Struts?
>
>Vinh
>

--
Eddie Bush




--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:

For additional commands, e-mail:




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

Re: Internationalization Broken on Struts 1.1b2?

[Craig R. McClanahan]

On Fri, 27 Sep 2002, Ryan Cuprak wrote:

> Date: Fri, 27 Sep 2002 16:54:26 -0400
> From: Ryan Cuprak <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Internationalization Broken on Struts 1.1b2?
>
> Okay, I figured it out, one has to add the following to their jsp page:
>   
>
> Why would I have to do this?
>

If you were flowing all requests through the controller servlet, you
wouldn't have to do this (assuming you have accepted the default
 setting for the "locale" attribute).  It sounds like you've
got users who are accessing the JSP page's URL directly, which therefore
bypasses the Struts controller.

> -Thanks,
>Ryan Cuprak

Craig


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

Re: [FRIDAY] [OT] Best misunderstanding of an acronym?

[Craig R. McClanahan]

On Fri, 27 Sep 2002, Kevin A. Smith wrote:

> Date: Fri, 27 Sep 2002 11:07:53 -0400
> From: Kevin A. Smith <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: [FRIDAY] [OT] Best misunderstanding of an acronym?
>
> The one that always baffles me is "TANSTAAFL".
>
> A quick Google search reveals "There Aint No Such Thing As A Free Lunch".
>

It's also going to be well known to Robert Heinlein's "The Moon Is A Harsh
Mistress", one of my favorite SF novels.

> --Kevin

Craig


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

Action Error

[Khan, Manuchehar A (ACF)]

Action Error must be impletmented in sorted order. Right now it appears to
be Hashtable...When we try to display errors they dont show up in order we
inserted...

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 6:35 PM
To: Struts Users Mailing List
Subject: Re: Globals




On Thu, 26 Sep 2002, Anthony Martin wrote:

> Date: Thu, 26 Sep 2002 19:58:11 -0700
> From: Anthony Martin <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: "Struts User List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Globals
>
> Is it now recommended to use members of Global like in Global.ERROR_KEY
> instead of Action.ERROR_KEY *even* in classes that extend Action?  I know
> these members have not been marked as deprecated, but the note seems to
> indecate that they are preferred:
>
> "Global manifest constants for the entire Struts Framework. Many of these
> constants were initially defined in Action, but were moved here so that
they
> could be referenced without referencing the Action class itself. For
> backwards compatibility, constant references there point at this class,
and
> the constant values themselves have not changed."
>
> So, it looks like either way is acceptable.  But will the old way be
> deprecated sometime in the future?
>

The old way is likely to be deprecated in the future, but not in 1.1.

I made a mistake originally in defining these constants in Action.java
instead of in their own class, but there's no going back now (by removing
them from Action).  And there is now a new flood of books that talks about
using Action based constants, so it seems impolite of us to deprecate them
in a 1.1 time frame ...

>
> Anthony
>

Craig


--
To unsubscribe, e-mail:

For additional commands, e-mail:


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

Re: Retrieving list of Roles defined in web.xml [Revised]

[Craig R. McClanahan]

On Fri, 27 Sep 2002, Vinh Tran wrote:

> Date: Fri, 27 Sep 2002 08:54:31 -0400
> From: Vinh Tran <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Retrieving list of Roles defined in web.xml [Revised]
>
> I can also manage if there is a simple way to identify the roles a user
> particpates in (using container managed security). There is a call for
> isUserInRole() but nothing for getUserRoles()?
>

There is no getUserRoles() method available in the servlet API, which
means that any answer you get is going to be application server dependent.
Indeed, it is incorrect to assume that the list of roles a user has is
static -- it's quite conceivable for your server to define a role as "is
it between 8:00am and 5:00pm on a weekday" and use that to limit the times
a particular application function is available.

You're going to need to research how your underlying app server stores and
accesses authentication information.

> Any ideas?
>
> Thanks.

Craig


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

Re: Is it really worth the effort to have a single instance of theAction?

[Craig R. McClanahan]

On Fri, 27 Sep 2002, Andrew Hill wrote:

> Date: Fri, 27 Sep 2002 15:51:06 +0800
> From: Andrew Hill <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Is it really worth the effort to have a single instance of the
> Action?
>
> Given that for modern JVMs object creation and cleanup isnt the chore it
> used to be , I am wondering if it might not be more convienient to create a
> new Action instance for each request.
>

The WebWorks framework (by Rickard Oberg) actually does things in the
manner you suggest, and goes one step further -- he combines what we think
of as the form bean and the Action into a single class, and calls all the
property setters for your request fields directly on the "Action" instance
before calling it's execute() method.  Therefore, no separate form bean
class is needed.

If I had thought of this design pattern in the first place, I'd have been
pretty tempted to use it.  However, changing the semantics of a
fundamental piece of Struts this radically doesn't seem like a good idea
at this point, because it would reduce performance (albeit by a small
amount) on existing Struts apps that are already programmed with thread
safe Actions.

The other concern I have is that this would encourage you to code your
business logic in the Action directly, instead of delegating it to some
logic bean.  I view the most appropriate role of an Action to be as an
adapter between the servlet-API-based web environment and the business
logic of your application, which should *not* depend on any presentation
layer APIs itself.


Craig


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

Re: use Jakarta TagLibs in Struts

[Craig R. McClanahan]

On Fri, 27 Sep 2002, Eddie Bush wrote:

> Date: Fri, 27 Sep 2002 00:12:52 -0500
> From: Eddie Bush <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: use Jakarta TagLibs in Struts
>
> I believe I saw a post in the commons-dev list that indicated the xsl
> taglib was "stale" and that a person should "upgrade" to the JSTL.
>

JSTL is absolutely, positively the way to go if you need XSLT
transformations in your JSP pages.  The only potential negative is that it
requires a Servlet 2.3 / JSP 1.2 container, but the benefits make a pretty
compelling argument to upgrade if you're not already on this platform.

Craig


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

Re: Globals

[Craig R. McClanahan]

On Thu, 26 Sep 2002, Anthony Martin wrote:

> Date: Thu, 26 Sep 2002 19:58:11 -0700
> From: Anthony Martin <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: "Struts User List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Globals
>
> Is it now recommended to use members of Global like in Global.ERROR_KEY
> instead of Action.ERROR_KEY *even* in classes that extend Action?  I know
> these members have not been marked as deprecated, but the note seems to
> indecate that they are preferred:
>
> "Global manifest constants for the entire Struts Framework. Many of these
> constants were initially defined in Action, but were moved here so that they
> could be referenced without referencing the Action class itself. For
> backwards compatibility, constant references there point at this class, and
> the constant values themselves have not changed."
>
> So, it looks like either way is acceptable.  But will the old way be
> deprecated sometime in the future?
>

The old way is likely to be deprecated in the future, but not in 1.1.

I made a mistake originally in defining these constants in Action.java
instead of in their own class, but there's no going back now (by removing
them from Action).  And there is now a new flood of books that talks about
using Action based constants, so it seems impolite of us to deprecate them
in a 1.1 time frame ...

>
> Anthony
>

Craig


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

newbie to struts

[Nellikkaltil, Liji]

hi there,
I am using Orion 1.5.2 on windows 2000 platform, I tried to deploy the 
struts-documenation.war file on orion using console and I get an error 
"com.evermind.server.ConfigFileNotFoundException: Unable to find/read assembly info 
for C:\orion\apachestruts\jakarta-struts-1.0.2\webapps\struts-documentation.war 
(META-INF/application.xml)"

If the answer to this has already been posted please let me know here I can find it.

thanks,
Liji



-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 6:22 PM
To: Struts Users Mailing List
Subject: RE: all this traffic




On Fri, 27 Sep 2002, adam kramer wrote:

> Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT)
> From: adam kramer <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: all this traffic
>
>
> There's seems to be alot of resistance to any sort of suggestion that
> might create better documentation and useability of Struts.
>

I can tell you for a fact that there's no resistance from Struts
*developers* on this.  What we resist, however, is the implication that
*we* should do all the work. :-)

Struts is an open source project.  The documentation is part of the source
code, in easily accessible formats (for Struts, it is XML files that are
post-processed to produce the HTML), and maintained in the same CVS
archives that the code is.

Users are welcome to submit enhancement requests (for either the code or
the documentation) via the bug tracking system:

  http://nagoya.apache.org/bugzilla/

and you can easily attach proposed patches to the enhancement requests.
The general outline of how to create the patches starts at:

  http://jakarta.apache.org/site/getinvolved.html

> Rather than telling people they have bad management skills, the obvious
> thing to do would be to actually listen and try to find solutions. There
> are lots of messages like Jonas's and there seems to be a core of people
> who are unwilling to listen or to change; it's like a chorus of people
> complaining about a bad interface and a group of developers just saying
> "get used to it buddy, always has been always will!"
>
> just an oh so humble suggestion.
>

My humble suggestion is to consider becoming part of the solution instead
of part of the complaining horde.  "Patches welcome".

> -adam k.
>

Craig


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


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

RE: all this traffic

[Craig R. McClanahan]

On Fri, 27 Sep 2002, adam kramer wrote:

> Date: Fri, 27 Sep 2002 10:17:19 -0400 (EDT)
> From: adam kramer <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: all this traffic
>
>
> There's seems to be alot of resistance to any sort of suggestion that
> might create better documentation and useability of Struts.
>

I can tell you for a fact that there's no resistance from Struts
*developers* on this.  What we resist, however, is the implication that
*we* should do all the work. :-)

Struts is an open source project.  The documentation is part of the source
code, in easily accessible formats (for Struts, it is XML files that are
post-processed to produce the HTML), and maintained in the same CVS
archives that the code is.

Users are welcome to submit enhancement requests (for either the code or
the documentation) via the bug tracking system:

  http://nagoya.apache.org/bugzilla/

and you can easily attach proposed patches to the enhancement requests.
The general outline of how to create the patches starts at:

  http://jakarta.apache.org/site/getinvolved.html

> Rather than telling people they have bad management skills, the obvious
> thing to do would be to actually listen and try to find solutions. There
> are lots of messages like Jonas's and there seems to be a core of people
> who are unwilling to listen or to change; it's like a chorus of people
> complaining about a bad interface and a group of developers just saying
> "get used to it buddy, always has been always will!"
>
> just an oh so humble suggestion.
>

My humble suggestion is to consider becoming part of the solution instead
of part of the complaining horde.  "Patches welcome".

> -adam k.
>

Craig


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

RE: all this traffic

[Craig R. McClanahan]

On Thu, 26 Sep 2002, Assenza, Chris wrote:

> Date: Thu, 26 Sep 2002 10:17:36 -0400
> From: "Assenza, Chris" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: all this traffic
>
> >Usually mailing list operators solve this problem
> >by separating mailing lists to a newbie list and
> >a list for more experienced users.
>
> >struts-user-beginner
> >struts-user
>
> Which was one thing he originally suggested... =p
>

While this idea is appealing in principle, it has dramatically failed to
achieve the objectives in every case I've seen it used.  Therefore, I'm
going to -1 any proposal to do this for Struts.

> /me
> Doesn't care so much, I simply don't have enough time to read all this
> stuff, I usually scroll by to see what catches my eye, otherwise I select
> all and delete. :)
>

Setting up your mail reader to automatically forward STRUTS-USER messages
to a separate folder, and then sorting by thread, is a trivially easy
approach to dealing with volume issues.  Your inbox is no longer clogged,
you can go read Struts mail when you have time, and can ignore entire
irrelevant threads with a single command to advance to the next thread.

> -Chris

Craig


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

RE: Struts and high performance sites revisited

[Craig R. McClanahan]

On Thu, 26 Sep 2002, Lister, Tom (ANTS) wrote:

> Date: Thu, 26 Sep 2002 13:21:45 +0100
> From: "Lister, Tom (ANTS)" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Struts and high performance sites revisited
>
> Hi
> I've recently been struggling with performance issues related to tags,
> especially where there are large number in some of our pages. The biggest
> improvment we got was by switching application servers. Specifically by
> upgrading to the latest Tomcat 4.1.11. The difference in response is
> incredible.
> So it would seem that the major issue is with the type of code generated by
> the servlet engine.
> We spent some time looking at the generated code, the major issue being that
> every tag reference is created as a new object. There must be better way to
> do this. Until this point I was wrongly assuming that the tags were run as
> just method calls on one instance.

The JSP Specification provides many standard opportunities that a JSP page
compiler can use to improve the quality of the generated code for a custom
tag invocation.  One of the simplest is to reuse tag instances (as the
Jasper 2 compiler in Tomcat 4.1 can do), but there are more aggressive
things you can do as well.  Consider something like this:

  

  

Not only is it legal to reuse the custom tag instance for the "bar" tag
(instead of creating 100 instances the way Tomcat 4.0 does), but the page
compiler need not even call the setName() and setValue() methods 100 times
inside the loop -- these can be moved outside the loop using standard
techniques that optimizing compilers have used for decades.

The JSP page compiler in Tomcat 4.1 and 5.0 (called "Jasper 2") was
rewritten from the ground up, primarily in order to make optimizations
like this possible.  You are seeing the fruits of this effort in 4.1, but
we are by no means done with improving the optimizations that the page
compiler can perform.

> will JSTL improve on this ?
>

JSTL by itself doesn't change the code that is generated for a custom tag
-- that's up to the page compiler.  But the page compiler does have the
opportunity to recognize JSTL tags (since they are a standard now) and
generate specially optimized code (for example, turning a  into
a real Java "for" statement instead of a custom tag invocation), as long
as the semantic requirements are met.  So, once the page compilers have
been improved in this manner, using  will definitely run faster
than a Struts  tag that iterates the same number of times
(unless someone were to optimize their page compiler for Struts tags,
which seems less likely than optimizing for JSTL :-).

> :-)
> Tom Lister
> * 020 7612 3030
> * [EMAIL PROTECTED]
>

Craig McClanahan


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

Re: Struts and high performance sites revisited

[Craig R. McClanahan]

On Thu, 26 Sep 2002, David Zimmerman wrote:

> Date: Thu, 26 Sep 2002 10:42:34 +0100
> From: David Zimmerman <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Struts and high performance sites revisited
>
> Ok, so we got it nailed down these statements...
>
> - The Struts Controller doesn't add more overhead than a high
> performance site should be able to handle. In the regard flexibility
> contra performance, using the controller makes your application
> manageable with negligible overhead.
>

That's a pretty good summary.  For the vast majority of Struts based
applications, the overhead of the Struts controller servlet is down in the
noise level percentages -- and, of course, if you were to consider
replacing it, you'd have to add back in the overhead of your replacement
solution anyway.

> - There was also the everlasting discussion on EJB's be or not to be. I
> think that there are loads of variables that affects the choices of the
> design and that there still remains some issues with EJB's. However when
> only using stateless session beans with DAO's I think that the
> scalability-flexability-performance goes hand in hand and makes a
> preferrable design choice. Anyone disagrees? Would be nice to hear your
> opinions.
>

There is no one correct answer to this question.  Anyone trying to answer
it with an absolute "always use EJBs" or "never use EJBs" should not be
considered a trustworthy source of advice.

What you *should* always start with is an understanding of your
application's functional requirements -- both initially, and the
directions it is likely to go.  Just as a silly example, if you're
building a simple intranet app for a ten-person department, with a
"database" content measured in kilobytes instead of megabytes, you should
just pick the technology you are the most familiar with and be done with
it -- even if your solution isn't "fastest possible", spending a couple of
hundred dollars more on your server hardware is ***much*** cheaper than
paying for the extra hours of development to learn a new technology.
However, if your development team knows the "stateless session bean +
DAOs" design pattern already, there's nothing wrong with using it.

> - But what was not discussed was the overhead of custom tags. This seems
> to be a question much avoided everywhere. When talking about
> flexability. Oh yes, use them. They makes your pages much easier to
> build and manage. They also makes for a great design of the application.
> BUT (capital letters), what about the performance overhead of the tags?
> When designing a web site where the absolute focus is to be able to
> handle as many transactions as possible to a low cost. Doesn't custom
> tags become very expensive to use in a case like this? There must have
> been extensive testing made on this. Does anyone have any facts or
> thoughts on this?

Here are two basic lines of thoughts to consider.

As with concern over the controller servlet's overhead, you can't just say
"custom tags are expensive so do not use them", without considering the
cost of whatever you are going to replace them with.  This matters a lot
more than the controller servlet's potential overhead in many cases, but
my experience is that the database tier tends to dominate the overall
performance overhead of a web app, no matter what technology you use for
the presentation tier.

Second, the performance overhead of custom tags is very much dependent
upon the quality of the JSP page compiler you are using, so it is (as with
most things) impossible to create absolute guidelines that cover every
possible situation.

As an example, you should try running the same Struts based app on the
current releases of Tomcat 4.0 (with the original JSP page compiler) and
Tomcat 4.1 (with the completely rewritten Jasper 2 page compiler that has
many optimizations to improve the generated code for custom tags).
Performance improvements on the order of 600% to 800% have been observed
on pages with lots of custom tags (which is typical of Struts apps), with
*zero* changes to the application itself.  You will see a very wide range
of performance when you try out various other app servers as well.

The moral of the story -- it's not custom tags that are fast or slow, it
is the JSP page compiler's generated code for those tags that is fast or
slow.  Without defining what app server (and version) you are talking
about, trying to ask about the performance of custom tags is a meaningless
question.

Craig McClanahan


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

RE: logic:iterate with nested html:img

[Vinh Tran]

Eddie:

Thanks for you help.  I promise this will be the last response on this
thread.  I just want to be certain that it is valid to use EL with Struts
tags.  Meaning, by using the  tag I should be able to access
this object using EL.  Or do I have to use  or  in order
to use EL?

By the way, I have tried everything from  to
Anyway, thanks again and I will just have to continue
troubleshooting.

Vinh

-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 12:33 AM
To: Struts Users Mailing List
Subject: Re: logic:iterate with nested html:img


Oh - cool!  Glad you could upgrade!

All you should have to do is drop the JAR you built into your app's lib
directory, copy the TLDs over into wherever you keep those, add
references to the taglibs in your web.xml, declare the taglib in your
page, and use them just like you would the Struts tags - BUT - you have
EL support.

If you're running Tomcat 4, why not install the JSTL and use that for
iteration?  :-)

I don't know what kind of errors you're getting in your page.  I think
things look like they are setup right.  One thing to remember is that
the EL is going to expect you to be following JavaBean patterns, so ...
is map.getSrcImage() valid?  is map.getDesc() valid?  If that's really a
map, you might want to try accessing it like map['srcImage'] and
map['desc'].

That's my best guess not knowing what problems you're having.

Vinh Tran wrote:

>Eddie:
>
>I'm finally up and running on Tomcat 4.0 but now I'm pulling my hair out
>trying to get EL to work.  Is it possible to use Struts-EL in conjunction
>with Struts tags?
>
>For example:
>scope="session" ignore="true"/>
>
>...later in the page I attempt to iterate through a collection...
>
>   
>
>
>Am I trying to defy the laws of physics, or at least Struts?
>
>Vinh
>

--
Eddie Bush




--
To unsubscribe, e-mail:

For additional commands, e-mail:




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

Property "errors.prefix" not used by HTML:errors ?

[Pel Oliver Kristiansen]

Hi all !

Complete newbe trying to get the  to print pretty.
I include the following into my ApplicationResources.properties

errors.header=Feil oppstod!
errors.prefix=*
errors.sufffix=
errors.header=

(ignore the lame tags they are just for testing)

The "errors.header" and "errors.header" are displayed but the 
"errors.prefix" and "errors.sufffix" are not.

(HTML example output:)

Feil oppstod!
Feltet inneholder for mye informasjon
Feltet Navn er ikke utfyllt


Any pointers ?

Pel O. Kristiansen


Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at 
http://www.eudoramail.com

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

RE: Disabling jsessionid parameter in Struts forms

[Craig R. McClanahan]

On Thu, 26 Sep 2002, Andrew Hill wrote:

> Date: Thu, 26 Sep 2002 17:11:41 +0800
> From: Andrew Hill <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Disabling jsessionid parameter in Struts forms
>
> You are correct about encodeURL() - this is when the sessionId is appended.
> The sessionId is part of the servlet API session tracking mechanism , and as
> you have noticed is appended to the URL when not using cookies. (When using
> cookies it is instead stored in a cookie).
> If you do not include the sessionId , you will not be able to make much use
> of session scope in your website (as each request will get a new session).
> If you dont need to use session scope to keep track of anything, this
> probably won't be a problem (I think - unless struts itself needs it for
> certain things?).
> As for actually disabling the appending of sessionId I am afraid I have no
> idea how you might achieve it with regards to the struts tags.
>

The "jsessionid" path parameter is indeed added by the call that Struts
automatically makes to response.encodeURL() when setting up URLs for you.
Without this automatic feature, you'd have to call encodeURL() yourself in
order to ensure that your application works when your client does not have
cookies enabled.

So, why does this get generated when my client *does* have cookies?  The
reason is that, on the first response for a particular session, the server
has no way to know if you have cookies enabled or not, so the session ID
is sent *both* ways (via URL rewriting and as a cookie).  If the session
ID comes back in as a cookie, the server will understand that it no longer
needs to rewrite from the second response on.

There is no configuration parameter to turn this off, and there won't be.
The important principle you should get used to is that the actual contents
of the request URL is pretty meaningless in a web application based on
Model 2 design patterns.  You're far better training yourself (and your
users) to ignore the URL completely rather than obsessing over the
detailed contents.

For stubborn users, I've occasionally resorted to running the app in a
frameset with a single frame, just so the location bar URL doesn't change
on every request ...

Craig McClanahan


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

Re: Proper exception handling of JDBC code? Need to call connection.rollback()?

[David Graham]

It's good practice to always put the rollback in the catch block and the 
close in the finally block.  Never depend on the Connection to do this for 
you.  It's not really because of defensive programming, it's to ensure the 
correctness of your data.

An easy way to not forget to do this is to create some kind of wrapper 
method that calls your implementation method.  The impl. method will throw 
SQLException and not have any catch blocks for database problems.  The 
wrapper method that called the impl. method catches SQLException and calls 
rollback.  It also calls conn.commit() if successful and conn.close in the 
finally block.  This reduces your JDBC code considerably.

Dave

>From: Bomb Diggy <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Proper exception handling of JDBC code?   Need to call 
>connection.rollback()?
>Date: Sat, 28 Sep 2002 16:40:57 -0700 (PDT)
>
>One of the many points I raised earlier was how to
>properly close a database connection, and how that
>might change depending on whether you were using
>connection pooling and/or a DataSource.  The example
>JDBC code cited was that in the Struts 1.0.2 Javadoc:
>
>http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/util/package-summary.html#doc.JDBC
>
>The part that looked a little funny to me and others
>was the call to [myConnection].rollback() in the
>catch{} block.  I think I finally figured out why this
>was put in - defensive programming.
>
>It seems to me that if *any* part of a transaction is
>successful, then [connection].rollback() needs to be
>called, else the next piece of application code that
>got its hands on that connection object and completed
>a transaction successfully would also complete the
>previously-uncommitted transaction.
>
>For example, let's say your updateDB() method has two
>separate method calls made within it that each update
>a table.  If only the first conn.executeUpdate()
>method completes successfully, and the second
>conn.executeUpdate() throws some kind of SQLException,
>that transaction will *not* automatically be rolled
>back.  The driver won't do it.  The database would do
>it only when the connection is finally closed.
>
>But what if that connection is part of a connection
>pool, and before the application server (and thus the
>pool) goes down for the night, that updateDB() method
>is used again, this time with success.  Now, the
>leftover transaction from the first failed call to
>updateDB() has been committed along w/ any changes
>from follow-on calls to updateDB().  All of this
>happens, if your DataSource/Connection Pooling
>Mechanism/Wrapped Connection Object isn't smart enough
>to call [connection].rollback() for you.  The
>GenericConnection object that ships with Struts is
>smart enough - and that's why I probably hadn't been
>burned in the past while using Struts, and not calling
>conn.rollback() myself.
>
>The GenericConnection object's first task in its
>close() method is to call connection.rollback().  So,
>as long as I call connection.close() before leaving my
>updateDB() method, I'm good to go.
>
>/*  Code snippet from Struts source */
>...
>// Clean up any outstanding transaction as best we can
>try {
>   conn.rollback();
>} catch (SQLException e) {}
>...
>
>Hope all this is correct...don't want to mislead
>people...
>
>
>__
>Do you Yahoo!?
>New DSL Internet Access from SBC & Yahoo!
>http://sbc.yahoo.com
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>




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


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

Re: all this traffic

[David Graham]

No, I'm not a committer (from my understanding of the term).  I can't commit 
anything to cvs, I've just submitted a few docs and maybe a patch for code.  
I understand that everything we submit won't get applied but if it's not 
going to be used they could at least post a response in bugzilla telling us 
why.  Without that it's a bit discouraging.

Dave


>From: Eddie Bush <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: all this traffic
>Date: Fri, 27 Sep 2002 10:50:28 -0500
>
>Well, David, you're a committer, right?  What would you suggest a person 
>do?  I hear you on the patches - but, to be honest, patches are suggestions 
>- there's no rule that states that they must be applied. The person 
>committing the changes may, in fact, have a different perspective on the 
>changes you made and not include your patch - but derive something from 
>your patch that does get committed.
>
>My view on filing a fix is:  Hey, here's my suggestion - oh, and I thought 
>it through enough that I actually coded it and made it compile and TESTED 
>it - it works for me.
>
>A good example of the debacle a commiter could find himself involved in is 
>this latest thing with sub-apps that Steve Ditlinger and I have been 
>hitting on.  I'm sure you've followed it.  The question is:  Do we ahere 
>strongly to this, or relax to include that too - that's a judgement call on 
>the part of the committer, IMHO.  My original patch was simply to make 
>things work the way I understood Craig wanted them to.  That didn't suit 
>Steve, so he submitted another patch for what he wanted.  Then, Martin 
>piped up and suggested neither of us fully comprehended the situation (and 
>we didn't!  He had good points!) and last night I hacked out another patch 
>- which I have yet to attack because I'm waiting for suggestions on whether 
>I've covered all the bases or not.  I think I have, but I can't claim to 
>know Struts as well as those who are commiters for this piece of the 
>machinery.  In the end, one of the three patches will probably be used, and 
>it's really irrelevant to me which one it is.  I just want sub-app 
>selection to be bulletproof :-)
>
>David Graham wrote:
>
>>Agreed, but it's frustrating when you submit a patch or documentation and 
>>its not applied or responded to.  It seems like they can get lost in the 
>>shuffle.
>>
>>Dave
>
>
>--
>Eddie Bush
>
>
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


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

Re: Help Re: cancel and session-scope form

[Angie Lin]

Thanks for the tip, but I'm trying to avoid javascript as much as 
possible.  It looks like I'll have to go ahead and manage my session 
form manually, and use a request-scoped form so that the auto-population 
doesn't blow away the properties.  

Thanks again,
Angie

Eddie Bush wrote:

> Actually ... I've never done this before, but ...
>
> Why couldn't you invoke a javascript method on your Cancel button that 
> invoked the forms reset method?  That might be the easiest solution ...
>
> Eddie Bush wrote:
>
>> Just quickly thinking it over ...
>>
>> When your form submits, you're going to hit an action.  Your action 
>> is going to look and see what the user told you they wanted to do and 
>> act appropriately.  Now, that doesn't help you keep the form from 
>> being populated, but you can certainly keep from updating your 
>> persistent storage using this information - and know that, instead, 
>> you should request fresh data to repopulate the form with.  I like to 
>> rename my buttons to something like "action" or "userAction" - and 
>> give all of them the same name - so I can judge off the value of that 
>> parameter what the user is telling me they'd like to have happen.
>>
>> That's my "spontaneous, first-cut" answer.  I can't think of a way to 
>> circumvent the population ... 
>
>
>

-- 
Angie Lin
[EMAIL PROTECTED]
408.519.9250



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

Only single attribute collections in ActionForm?

[Frederic Laub]

Hi,

I'm building a web application using Struts, all the aspects of the
framework are new to me.
I try to stick to the MVC design, the Model and Controller are quite clear
to me.
Thanks to the wonderful work of the Struts team and in particular Chuck
Cavaness and his Jakarta Struts Book Review.
I still don't know how to design my view components and FormActions, maybe
because of the missing chapter 8 (Custom Tag Libraries) of the review?
Question 1) Where can I find this missing chapter? (PS I pre-ordered the
book)
I want to stick to the struts tag-lib and their use with FormBeans but I
didn't find any convincing example of ActionForms for composed input pages.
I have a page with a table, in each cell is a picture with display
attributes (number, comment, link, ...) and input fields (check box for
selection, quantity, ... ), the last cells may be empty (conditional
display).
I designed a PageView which is composed of PictureViews (with all the
attributes for one cell).
Question 2) Where can I find an example for building this kind of JSP page
with multi-level nested Struts tags (iterate, logic, ...) which will be used
as input of an ActionForm?
Question 3) Do I need to decompose my input attributes in my ActionForm to
simple Arrays/ArrayLists (Is it a best practise?):
selectedPictures[]
pictureNumbers[]
orderedQuanties[]

Your help will be appreciated!!
Frederic

PS Mastering jakarta Struts is already part of Java collection.



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

Re: Help Re: cancel and session-scope form

[Eddie Bush]

Actually ... I've never done this before, but ...

Why couldn't you invoke a javascript method on your Cancel button that 
invoked the forms reset method?  That might be the easiest solution ...

Eddie Bush wrote:

> Just quickly thinking it over ...
>
> When your form submits, you're going to hit an action.  Your action is 
> going to look and see what the user told you they wanted to do and act 
> appropriately.  Now, that doesn't help you keep the form from being 
> populated, but you can certainly keep from updating your persistent 
> storage using this information - and know that, instead, you should 
> request fresh data to repopulate the form with.  I like to rename my 
> buttons to something like "action" or "userAction" - and give all of 
> them the same name - so I can judge off the value of that parameter 
> what the user is telling me they'd like to have happen.
>
> That's my "spontaneous, first-cut" answer.  I can't think of a way to 
> circumvent the population ... 


-- 
Eddie Bush




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

Re: Help Re: cancel and session-scope form

[Eddie Bush]

Just quickly thinking it over ...

When your form submits, you're going to hit an action.  Your action is 
going to look and see what the user told you they wanted to do and act 
appropriately.  Now, that doesn't help you keep the form from being 
populated, but you can certainly keep from updating your persistent 
storage using this information - and know that, instead, you should 
request fresh data to repopulate the form with.  I like to rename my 
buttons to something like "action" or "userAction" - and give all of 
them the same name - so I can judge off the value of that parameter what 
the user is telling me they'd like to have happen.

That's my "spontaneous, first-cut" answer.  I can't think of a way to 
circumvent the population ...

Angie Lin wrote:

> Any ideas are appreciated.
>
> Is there anyway to keep my session-scoped form from being populated by 
> a click of an  button?  Is there any hook in the 
> underlying Action that I can intercept prior to the ActionForm 
> auto-population?
>
> Thanks,
> Angie 


-- 
Eddie Bush




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

Help Re: cancel and session-scope form

[Angie Lin]

Any ideas are appreciated.

Is there anyway to keep my session-scoped form from being populated by a 
click of an  button?  Is there any hook in the underlying 
Action that I can intercept prior to the ActionForm auto-population?

Thanks,
Angie


Angie Lin wrote:

> Hi there,
>
> How can I prevent a cancel button from populating the form bean? 
> Normally this isn't a problem, except that my form bean is in 
> session-scope (for an wizard-like implementation).
>
> I've considered reconfiguring it so that the form stays in 
> request-scope for each page in the wizard.  I would then instantiate 
> the form in session-scope myself and manage the copying of form fields 
> from each page manually depending on if the user submitted or 
> cancelled.  But I was hoping for a simpler solution.
>
> thanks,
> Angie
>
>
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 


-- 
Angie Lin
[EMAIL PROTECTED]
408.519.9250



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