RE: [VOTE] Convert RC2 to Beta 5

[dhay]

Go Martin!!!




"Martin Cooper" <[EMAIL PROTECTED]> on 08/06/2003 08:25:53 PM

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

To:"'Struts Developers List'" <[EMAIL PROTECTED]>
cc:
Subject:RE: [VOTE] Convert RC2 to Beta 5




> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2003 4:56 PM
> To: 'Struts Developers List'
> Subject: RE: [VOTE] Convert RC2 to Beta 5
>
>
> I'm not going to vote right now, because I'm trying to work
> through the
> problems and see if I can get them fixed. Ted, how long do we
> have to find
> fixes and still allow you enough time to get a release out?
>
> If we take the 'name' row out of the bean-cookie.jsp test, then the
> remainder of that test works fine on Tomcat 3.3.1. I propose
> to go ahead and
> check that in unless I hear any objection.
>
> Now I'm looking at the logic-compare.jsp problem.

OK, I have this one nailed. It has to do with the size of the page being
too
big for Tomcat 3.3.1 to handle. I've split the page into two by pulling out
the numeric tests into a separate page, and both pages now work. Again, I
propose to check this in unless I hear any objection.

Now for the Tiles problems...

--
Martin Cooper


> If anyone
> else has some
> time to look into the problems, might I suggest looking at
> the Tiles-related
> ones that Ted mentioned?
>
> --
> Martin Cooper
>
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, June 08, 2003 3:14 PM
> > To: Struts Developers List
> > Subject: [VOTE] Convert RC2 to Beta 5
> >
> >
> > In final testing of RC2, some compatibility issues have been found
> > between Tomcat 3.3.1 and the struts-exercise-taglib
> > application as well
> > as the tiles-documentation application.
> >
> > Martin Cooper has been looking into the problems and has
> > found that for
> > the struts-exercise-taglibs cookie test, it is the
> >
> >
> >
> > expression that is failing.
> >
> > The  tags earlier on the page succeeded. The only
> > difference seems to be that the earlier ones all have setters
> > as well as
> > getters in the Tomcat CookieFacade class, whereas there is
> > only a getter
> > for 'name'. So this actually looks like some kind of
> > JSP/reflection bug,
> > not related to Struts. (The  tag must have
> > worked, because
> > we know the  tag is trying to access a cookie!)
> >
> > Also, the (rather complex) comparison test is killing the JVM
> > when run
> > under TC3.
> >
> > In the Tiles application, servlet exceptions are being noted. One
> > example is the extendedDefinitionTag page, but there may be others.
> >
> > Unless fixes to these problems are immediately forthcoming,
> I propose
> > that we document the issues and release Stuts 1.1 beta 5.
> >
> > By getting this milestone out to the community, we would have
> > a better
> > chance of resolving the remaining issues so that we can go
> to Struts
> > 1.1. final as soon as possible
> >
> > This proposal has my +1.
> >
> > -Ted.
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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









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

Re: upgrading to 1.1 nightly

[dhay]

Sorry - found struts-config dtd!!!

Cheers,

David





"David_Hay/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com on 07/23/2002 06:07:52
PM

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

To:   "Struts Developers List"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





Cool.  Where can I find documentation on the new format for struts-config.xml /
 info?

Thanks,

David





"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/23/2002
04:51:19 PM

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

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 16:18:35 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Yep, saw that.
>
> To override that method, then, do I have to subclass both ActionServlet (to
> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
> all this made it easier to plug stuff in?  ;-)
>

You will need to subclass RequestProcessor with your change to the
processActionPerform() method, but you will not have to subclass
ActionServlet for this.

To override the default RequestProcessor class for a particular
application module, use the "processorClass" attribute of the 
element in the struts-config.xml file for that module (different modules
can use different request processors if they want to, which was the
primary reason it was abstracted out).

> Or am I missing something...?
>
> Cheers,
>
> David
>

Craig


>
>
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> on
07/18/2002
> 05:58:11 PM
>
> Please respond to "Struts Developers List"
>   <[EMAIL PROTECTED]>
>
> To:   Struts Developers List
>   <[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: upgrading to 1.1 nightly
>
>
>
> The request processing code that was in ActionServlet in 1.0 got migrated
> to a separarate class (RequestProcessor) in 1.1.
>
> Craig
>
>
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 18 Jul 2002 16:45:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: upgrading to 1.1 nightly
> >
> >
> >
> > Hi.
> >
> > Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> > following method which we were overriding no longer exists!  Should we
simply
> > override process() now?
> >
> >/**
> > * Ask the specified Action instance to handle this request.  Return
> > * the ActionForward instance (if any) returned by
> > * the called Action.
> > *
> > * @param action the Action to process this request
> > * @param mappingthe ActionMapping we are processing
> > * @param formInstance   the ActionForm we are processing
> > * @param requestthe servlet request we are processing
> > * @param response   the servlet response we are creating
> > * @exception IOExceptionif an input/output error occurs
> > * @exception ServletException   if a servlet exception occurs
> > */
> >protected ActionForward processActionPerform (Action action,
ActionMapping
> > mapping,
> >  ActionForm formInstance,
> >  HttpServletRequest request,
> >  HttpServletResponse
response)
> > throws IOException, ServletException
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > --
> > 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 additional commands, e-mail: 








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








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

Re: upgrading to 1.1 nightly

[dhay]

Cool.  Where can I find documentation on the new format for struts-config.xml /
 info?

Thanks,

David





"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/23/2002
04:51:19 PM

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

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly





On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Tue, 23 Jul 2002 16:18:35 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: upgrading to 1.1 nightly
>
>
>
> Yep, saw that.
>
> To override that method, then, do I have to subclass both ActionServlet (to
> override getRequestProcessor()) and subclass RequestProcessor too?  I thought
> all this made it easier to plug stuff in?  ;-)
>

You will need to subclass RequestProcessor with your change to the
processActionPerform() method, but you will not have to subclass
ActionServlet for this.

To override the default RequestProcessor class for a particular
application module, use the "processorClass" attribute of the 
element in the struts-config.xml file for that module (different modules
can use different request processors if they want to, which was the
primary reason it was abstracted out).

> Or am I missing something...?
>
> Cheers,
>
> David
>

Craig


>
>
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> on
07/18/2002
> 05:58:11 PM
>
> Please respond to "Struts Developers List"
>   <[EMAIL PROTECTED]>
>
> To:   Struts Developers List
>   <[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: upgrading to 1.1 nightly
>
>
>
> The request processing code that was in ActionServlet in 1.0 got migrated
> to a separarate class (RequestProcessor) in 1.1.
>
> Craig
>
>
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:
>
> > Date: Thu, 18 Jul 2002 16:45:26 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: upgrading to 1.1 nightly
> >
> >
> >
> > Hi.
> >
> > Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> > following method which we were overriding no longer exists!  Should we
simply
> > override process() now?
> >
> >/**
> > * Ask the specified Action instance to handle this request.  Return
> > * the ActionForward instance (if any) returned by
> > * the called Action.
> > *
> > * @param action the Action to process this request
> > * @param mappingthe ActionMapping we are processing
> > * @param formInstance   the ActionForm we are processing
> > * @param requestthe servlet request we are processing
> > * @param response   the servlet response we are creating
> > * @exception IOExceptionif an input/output error occurs
> > * @exception ServletException   if a servlet exception occurs
> > */
> >protected ActionForward processActionPerform (Action action,
ActionMapping
> > mapping,
> >  ActionForm formInstance,
> >  HttpServletRequest request,
> >  HttpServletResponse
response)
> > throws IOException, ServletException
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > --
> > 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 additional commands, e-mail: 








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

Re: upgrading to 1.1 nightly

[dhay]

Yep, saw that.

To override that method, then, do I have to subclass both ActionServlet (to
override getRequestProcessor()) and subclass RequestProcessor too?  I thought
all this made it easier to plug stuff in?  ;-)

Or am I missing something...?

Cheers,

David




"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/18/2002
05:58:11 PM

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

To:   Struts Developers List
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: upgrading to 1.1 nightly



The request processing code that was in ActionServlet in 1.0 got migrated
to a separarate class (RequestProcessor) in 1.1.

Craig


On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Thu, 18 Jul 2002 16:45:26 -0400
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: upgrading to 1.1 nightly
>
>
>
> Hi.
>
> Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
> following method which we were overriding no longer exists!  Should we simply
> override process() now?
>
>/**
> * Ask the specified Action instance to handle this request.  Return
> * the ActionForward instance (if any) returned by
> * the called Action.
> *
> * @param action the Action to process this request
> * @param mappingthe ActionMapping we are processing
> * @param formInstance   the ActionForm we are processing
> * @param requestthe servlet request we are processing
> * @param response   the servlet response we are creating
> * @exception IOExceptionif an input/output error occurs
> * @exception ServletException   if a servlet exception occurs
> */
>protected ActionForward processActionPerform (Action action, ActionMapping
> mapping,
>  ActionForm formInstance,
>  HttpServletRequest request,
>  HttpServletResponse response)
> throws IOException, ServletException
>
> Thanks,
>
> David
>
>
>
>
>
> --
> 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: 

upgrading to 1.1 nightly

[dhay]

Hi.

Am upgrading an app from 1.0 to 1.1 nightly build, and discovered that the
following method which we were overriding no longer exists!  Should we simply
override process() now?

   /**
* Ask the specified Action instance to handle this request.  Return
* the ActionForward instance (if any) returned by
* the called Action.
*
* @param action the Action to process this request
* @param mappingthe ActionMapping we are processing
* @param formInstance   the ActionForm we are processing
* @param requestthe servlet request we are processing
* @param response   the servlet response we are creating
* @exception IOExceptionif an input/output error occurs
* @exception ServletException   if a servlet exception occurs
*/
   protected ActionForward processActionPerform (Action action, ActionMapping
mapping,
 ActionForm formInstance,
 HttpServletRequest request,
 HttpServletResponse response)
throws IOException, ServletException

Thanks,

David





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

Re: tabular radio buttons :(

[dhay]

Much better way is to stick everything in an ArrayList of beans which you
iterate through.  That way no logic-present tags - radio buttons will pick up
values from underlying values.

for update, you'll need either indexed tags or nested tags.

cheers,

Dave





Chakradhar Tallam <[EMAIL PROTECTED]> on 04/29/2002
11:47:35 PM

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

To:   "'[EMAIL PROTECTED]'"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  tabular radio buttons :(



hi guys,

i've a page with radio buttons in 4 rows & 5 columns = 20 radio buttons.
each column's radio button's on/off property comes from a bean = 5 beans.
only one radio button in a row can be selected (one of 4 in each row), that
means the radio buttons each row should have the same name. i got this
working & i can display the on/off info of each radio button properly.

the problem comes while updating, i've created a form bean with 4 boolean
properties, get & set methods. while setting if a radio button in a row is
selected how will i know which bean that belongs to (remember radio buttons
in a row have same name)!

am i going in a worng direction! is there a better way doing this! if so,
please provide me few examples. help is appreciated.

jsp code of one of the rows
 
  
   
  




  




  









  









  

 


  




  




  




 

a sample out put is attached
 <>
thanks in advance.
Chakradhar Tallam
Consultant Software Engineer
Object Oriented Pty Ltd.,
Level 11 / 75 Miller Street, North Sydney, NSW - 2060
Phone: +61 2 9459 3356 Fax: +61 2 9955 6659
Web: http://www.oopl.com.au/







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







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

Re: Unsubscribe me

[dhay]

read the bottom of your email!





"Gujral, Irvind" <[EMAIL PROTECTED]> on 11/02/2001
03:23:50 PM

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

To:   "'Struts Developers List'"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Unsubscribe me



Unsubsribe me!!



-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 2:17 PM
To: Struts Developers List
Subject: RE: Validator design considerations



--- "Sobkowski, Andrej" <[EMAIL PROTECTED]>
wrote:
> Ted,
>
> thanks for your answer.
>
> I understand your idea of "initial validation". And
> I also agree with
> "Generally, objects should have dominion over their
> own data". But in the
> case of the validation process, IMHO the bean is the
> data used by a
> potentially external validation process (and not
> vice-versa). What if the
> validation on the same bean is different depending
> on the app context? It
> wouldn't be "clean" (for lack of better word) to
> consider both validations
> inside the bean itself (validate())... hence the
> advantage of having
> separate validation processes on the same bean
> (related to different app
> contexts i.e. different actions). Am I missing the
> point?
Since the ActionForm is directly associated to the
form, it wouldn't necessarily be shared.  But a pure
Address JavaBean could be shared by two ActionForms by
using nested properties.

>
> >We could definately use more standard, backend
> validators, but,
> >personally, I would say that the framework object
> that calls the
> >standard validator with the property in question
> should be the
> >ActionForm, or a business object, and not the
> Action or ActionServlet
> >directly.
>
> In the current Struts version, the validate() on the
> FormBean is called by
> the ActionServlet.performValidate(...) method, isn't
> it? The validation is
> part of the whole process that is controlled by the
> ActionServlet - from a
> "procedural" point of view - and the same applies if
> the validate() is in
> the FormBean or in the Action (the call is simply
> made on different entities
> but in the same place). Or not?
>
> A salomonic suggestion :) we could have different
> levels of validators:
> bean-related and action-related. The first ones will
> take care of
> first-level validations that always apply to the
> bean; the second will be
> context-specific and called only if the first
> validations passed. But by
> separating the validation process (by taking it out
> of the bean itself), it
> would be possible to dynamically associate a
> validation process (validator)
> with a bean/action.
The association of a bean with a set of validation
rules is purely based on the form element's name
attribute (the key) and the value you pass into the
Validator when you initialize it to run.  Most people
use the ValidatorForm which associates the this to the
name of the form (mapping.getAttribute()).  But you
could extend the ValidatorForm and use anything for a
key and make dynamic associations if you wanted too.
You could even apply a basic default bean validation
and then a custom one.

>
> Example in struts-config.xml:
> 
>
>   
> 
>
> 
>  type="com.mycompany.myFormBean">
>(see previous message
> for details)
>   
> 
>   
>  type="com.mycompany.myFormBean2">
>(link to
> validator defined above)
> 
>
> 
> 
> type="com.mycompany.myActionWithValidation"
>name="myForm">
>(see previous message
> for details)
> 
>
> Again, in my personal opinion, all of the above
> would be cleaner by
> separating the validators from the beans themselves.
> Did I manage to change
> your mind? :)
If the ActionForm was just a pure data bean I would
agree, but it isn't really.  There are already a
number of layers to the current system to add and
customize funcionality.  I do like the idea of having
a base set of validations you could define and
reference.

David

>
> Andrej
>
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 02, 2001 12:40 PM
> To: Struts Developers List
> Subject: Re: Validator design considerations
>
>
> Andrej Sobkowski wrote:
> > - The form bean itself is a "special data holder"
> and shouldn't be aware
> of
> > how its data is validated. Do you agree?
>
> I'm not sure that I do. I like to think of the
> ActionForm as a firewall.
> If it has passes the intial validation, then I know
> it is "safe" to use,
> and can passed along to business methods. Generally,
> objects should have
> dominion over their own data.
>
> Under the current model, the bean is not even passed
> to the Action until
> it is validated. The Action may undertake additional
> validation, usually
> in collaboration with the business model, but I
> think it is valid for an
> ActionForm to know whether it's String values pass
> some form of "prima
> facia" validation.
>
> There is usually additional validation at 

Descriptions for indexed tags

[dhay]

Hi.  Wanting to change the descriptions for the indexed tags in the docs to make
things a little clearer.  Propose the following:

for tags which inherit from BaseInputTag:

Valid only inside of logic:iterate tag.
If true, the name of the html tag will be rendered as
"myBean[34].myPropertyName" allowing for auto-updating using
getMyBean(34).setMyPropertyName(value).  The number in brackets
reflects the
current iteration index, taken from the ancestor logic:iterate
tag.

for other tags, apart from link:

Valid only inside of logic:iterate tag.
If true, the name of the html tag will be rendered as
"myPropertyName[34]".  The number in brackets reflects the
current iteration index, taken from the ancestor
logic:iterate tag.

and for link tag:

   Valid only inside of logic:iterate tag.
   If true then a parameter holding the current iteration index will

   be added to the query string.  By default this parameter is named

   "index", but may be assigned a different name using the "indexId"

   attribute.  The number in brackets reflects the current iteration
 index,
 taken from the ancestor logic:iterate tag.

Is that clear enough?

Cheers,

Dave




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

Building nightly build - tiles classpath problem

[dhay]

Hi.  I am building the nightly build, which now includes building the Tiles
dist.

I get compilation errors, however, due to a classpath problem.  Everything
builds fine on the Struts side, using the relative paths set up in
build.properties.  However, when it gets to Tiles, the base directory is now the
contrib/tiles dir, and the relative paths for servlet.jar etc are no longer
valid.  eg commons-beanutils.jar=../commons-beanutils-1.0/commons-beanutils.jar,
which when you go "down" two directories to the tiles dir, is no longer pointing
at the right place.

I have played around with things a little, and can't figure out a way to sort
this out, without added separate properties in the tiles build.xml.

Any ideas?

Cheers,

Dave




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

Re: [PATCH] nested iterates and the indexed attribute

[dhay]

Hi Tom,

apologies - I didn't read your initial note thoroughly enough - I thought you
were submitting a patch to allow for nested iterates, not just fixing the
problem of using an outer iterate param in the inner iterate.  You can ignore my
comments for that case!

Have looked at your patch, and it will fail if name=null when the prepareIndex
method is called.  This is the case with some of the tags eg button, and submit
(and img and image changes which I am about to submit).

Could you add a check for this?

Cheers,

Dave





"Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]> on
10/31/2001 11:47:09 AM

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

To:   "Struts Developers List"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  [PATCH] nested iterates and the indexed attribute



In case the answer is positive ("yes, this is a bug and not expected
behaviour"), I hereby attach a patch to solve it.

Tested with the html:radio tag, and it should work for all tags that
extend BaseHandlerTag (which, I presume but did not check, will be all
tags that can be indexed)

Let me know what you think about it,

tomK


> -Original Message-
> From: Tom Klaasen (TeleRelay)
> Sent: woensdag 31 oktober 2001 17:09
> To: Struts Developers List
> Subject: nested iterates and the indexed attribute
>
>
> Hi all,
>
> I think I discovered a bug in struts (nightly build 20011018):
>
> when I use nested iterates, the indexed attribute is always
> referring to
> the innermost iterate index, not the one which name is specified.
>
> so when I do
>
> 
> property="inner">
>  value="someValue" indexed="true"/>
>
> 
>
> I get something like
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> instead of the expected
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> (watch the indexes)
>
> (Of course, "someValue" would be replaced by something that
> is computed
> and makes more sense. This computation is omitted here for simplicity)
>
> Now, should I in fact consider this a bug and try to solve this, or do
> you think this is expected behaviour?
>
>
> thanks,
> tomK
>
> --
> To unsubscribe, e-mail:
>  [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: 
>
>

 BaseHandlerTag.java.diff



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







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

Re: [PATCH] nested iterates and the indexed attribute

[dhay]

Oops, finished the last note too quick...

Does the patch work if the inner iterate only has a name and not a property?
When I first looked at it ages ago, I ran into problems if the outer iterate
returned a collection for each step which I then wanted to iterate over... (if
that makes sense!)

Cheers,

Dave





"Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]> on
10/31/2001 11:47:09 AM

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

To:   "Struts Developers List"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  [PATCH] nested iterates and the indexed attribute



In case the answer is positive ("yes, this is a bug and not expected
behaviour"), I hereby attach a patch to solve it.

Tested with the html:radio tag, and it should work for all tags that
extend BaseHandlerTag (which, I presume but did not check, will be all
tags that can be indexed)

Let me know what you think about it,

tomK


> -Original Message-
> From: Tom Klaasen (TeleRelay)
> Sent: woensdag 31 oktober 2001 17:09
> To: Struts Developers List
> Subject: nested iterates and the indexed attribute
>
>
> Hi all,
>
> I think I discovered a bug in struts (nightly build 20011018):
>
> when I use nested iterates, the indexed attribute is always
> referring to
> the innermost iterate index, not the one which name is specified.
>
> so when I do
>
> 
> property="inner">
>  value="someValue" indexed="true"/>
>
> 
>
> I get something like
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> instead of the expected
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> (watch the indexes)
>
> (Of course, "someValue" would be replaced by something that
> is computed
> and makes more sense. This computation is omitted here for simplicity)
>
> Now, should I in fact consider this a bug and try to solve this, or do
> you think this is expected behaviour?
>
>
> thanks,
> tomK
>
> --
> To unsubscribe, e-mail:
>  [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: 
>
>

 BaseHandlerTag.java.diff



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







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

Re: [PATCH] nested iterates and the indexed attribute

[dhay]

Tom,

The nested iterates with indexed attribute has not, until this point, been
implemented.  So, what you saw was expected in one sense, but bug in another!

Had a quick look at your patch - looks good, but haven't had time to try it out.

Cheers,

Dave





"Tom Klaasen (TeleRelay)" <[EMAIL PROTECTED]> on
10/31/2001 11:47:09 AM

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

To:   "Struts Developers List"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  [PATCH] nested iterates and the indexed attribute



In case the answer is positive ("yes, this is a bug and not expected
behaviour"), I hereby attach a patch to solve it.

Tested with the html:radio tag, and it should work for all tags that
extend BaseHandlerTag (which, I presume but did not check, will be all
tags that can be indexed)

Let me know what you think about it,

tomK


> -Original Message-
> From: Tom Klaasen (TeleRelay)
> Sent: woensdag 31 oktober 2001 17:09
> To: Struts Developers List
> Subject: nested iterates and the indexed attribute
>
>
> Hi all,
>
> I think I discovered a bug in struts (nightly build 20011018):
>
> when I use nested iterates, the indexed attribute is always
> referring to
> the innermost iterate index, not the one which name is specified.
>
> so when I do
>
> 
> property="inner">
>  value="someValue" indexed="true"/>
>
> 
>
> I get something like
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> instead of the expected
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> (watch the indexes)
>
> (Of course, "someValue" would be replaced by something that
> is computed
> and makes more sense. This computation is omitted here for simplicity)
>
> Now, should I in fact consider this a bug and try to solve this, or do
> you think this is expected behaviour?
>
>
> thanks,
> tomK
>
> --
> To unsubscribe, e-mail:
>  [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: 
>
>

 BaseHandlerTag.java.diff



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







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

RE: OS / Browser tag?

[dhay]

Hi Jay,

Yeah, coming down to having two tags.  Would be great to add them to
logic:present tag, but not sure it would work - seems to me there is a
fundamental difference in that logic:present is checking for values in the
request.

What do others think?

Dave

PS  Cross posting to dev list too.




Jay Patel <[EMAIL PROTECTED]> on 10/04/2001 11:11:34
AM

Please respond to [EMAIL PROTECTED]

To:   "'[EMAIL PROTECTED]'"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  RE: OS / Browser tag?



I like the idea for the OS and Browser check. However I would suggest that
the checks be made separately and not within one tag. How about if we can
modify the logic:present to have two more parameters? ( that can also go for
notPresent ).

E.g.


  



  


Above approach will result in less of a learning curve and fewer tags.

My $0.02

Jay Patel
[EMAIL PROTECTED]



-Original Message-
From: Assenza, Chris [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 8:13 AM
To: '[EMAIL PROTECTED]'
Subject: RE: OS / Browser tag?


I have something written that will do the server-side browser detection,
etc. but not a tag for it. It's actually an adaptation of a nice PHP-based
script that I stumbled on a while back. :) It'd be a great idea for a tag
though - go for it! :)

Chris

Christopher Assenza
Phone:412.201.6026
Fax: 412.201.6060
Email:[EMAIL PROTECTED]
ACCESSDATA
Moving Your Business from Point A to Point e.SM http://www.accessdc.com/



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 03, 2001 4:59 PM
To: [EMAIL PROTECTED]
Subject: Re: OS / Browser tag?




Sorry, maybe that wasn't clear!

I am basically looking for an IF tag which utilises the OS and/or the
browser that the client is running on.

eg IF Unix and Netscape THEN
would be 
  //do something

and the tag would automatically check for current client os and browser.

Hope that's clearer!

Cheers,

Dave





"David_Hay/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com on 10/03/2001
04:17:59 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  OS / Browser tag?





Hi everyone.

Just wondering if anyone has written a tag to do something specific to OS or
Browser?

I'm probably going to write my own if no-one else has already done it!

Cheers,

Dave

Re: how to make the textfield uneditable

[dhay]

add disabled=true.

You should really post these type of questions to the user list

Dave





"Lu, Jennifer" <[EMAIL PROTECTED]> on 09/27/2001
04:54:25 PM

Please respond to [EMAIL PROTECTED]

To:   "'[EMAIL PROTECTED]'"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  how to make the textfield uneditable



Hi, there:

I am using the  tag and I want to make the field uneditable. Does
sb know how and could you please kindly give me some hint? Thanks.

Jen


Title: how to make the textfield uneditable





Hi, there:


I am using the  tag and I want to make the field uneditable. Does sb know how and could you please kindly give me some hint? Thanks.

Jen 

Niall's if/then/else tags?

[dhay]

Hi.  Just wondering what the status is on Niall's IF/THEN/ELSE tags being added
to the nightly build?

Cheers,

Dave

RE: Indexed Tags (TextArea)

[dhay]

Oleg has just committed the necessary changes, so they should be in the build
tomorrow.

You should be able to add the files that were attached to a previous mail too
the current nightly build src, and build it correctly though.

Cheers,

Dave





"Henry Mugasha" <[EMAIL PROTECTED]> on 09/05/2001 11:35:31 AM

Please respond to [EMAIL PROTECTED]; Please
  respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  RE: Indexed Tags (TextArea)



Hi Nathan,

THanks alot for the Info!! However, I have searched through a couple of the
nightly builds ( from 22nd August to 04 September ) in the binaries and src' but
none of these have the Textarea Tag implementation you have in the TextareaTag
file you sent as attachment. Do you know which build contains the Textarea tag
impl'.
I noticed that someone has added the prepareIndex method in the BaseHandlertag
so I tried using that setup, but I get alot of problems with the builr jar file
(from Aug-22-2001) since some classes have changed locations (i.e Digester, etc.
even though I place the latest struts.jar, commons*.jar files in my classpath
and the WEB-INF/lib directories)

Anyway, I tried simply adding your Textareatag file attachment to my old src
files (I used to build the latest stable release which works for indexed Text
Tags) and rebuilding with jakarta-ant but get the following error message
(below).I have checked and found out that the TextareaTag extends BaseInputTag
abstract class which extends BaseHandlerTag class that contains the indexed
protected variable. Now since TextareaTag is a descendant of BaseHandlerTag, I
would expect the compiler to figure this out. Do you know the probable cause of
this? Please help.

compile.library:
[javac] Compiling 135 source files to C:\downloads\struts\src\jakarta-struts
-1.0-src\target\library\classes
[javac] C:\downloads\struts\src\jakarta-struts-1.0-src\src\share\org\apache\
struts\taglib\html\TextareaTag.java:118: cannot resolve symbol
[javac] symbol  : variable indexed
[javac] location: class org.apache.struts.taglib.html.TextareaTag
[javac] if ("true".equals(indexed))
[javac]   ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error

BUILD FAILED


Your help is highly appreciated.

Henry

---

On Tue, 4 Sep 2001 17:20:04
 Nathan Coast wrote:
>check this message
>
>http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02891.html
>
>not sure if the change has been included in current dev but heres a patch
>for 1.0
>
>Nathan
>
>-Original Message-
>From: Henry Mugasha [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, September 04, 2001 4:59 PM
>To: [EMAIL PROTECTED]
>Subject: Indexed Tags (TextArea)
>
>
>Hi,
>
>The struts-html taglib allows for indexed tags on almost all form tags
>apart form the textarea form tag. Why is this so? Can this be easily fixed?
>
>Henry
>
>
>Get 250 color business cards for FREE!
>http://businesscards.lycos.com/vp/fastpath/
>
>
>
>**
>This email and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they
>are addressed. If you have received this email in error please notify
>the system manager.
>
>This footnote also confirms that this email message has been swept by
>MIMEsweeper at LevelSeas for the presence of computer viruses.
>
>www.mimesweeper.com
>**
>


Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/

Re: Submiting a form when selecting an option

[dhay]

You could do it with Javascript - on the select onchange method, call the form's
submit().

Dave





Rogerio Zamboim <[EMAIL PROTECTED]> on 08/30/2001
01:52:29 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Submiting a form when selecting an option







Hi,

I have a JSP page that bringing me a list of object names,
in a select form object, retrived from a database
and I would like to know if there is a way to submit the form (to bring
the rest of the object´s information) when selecting an option
without having to click on a button.

Tx for the help.

Rogerio Zamboim
CPqD Telecom & IT Solutions
Brazil

Re: dave hayes indexed properties / text area

[dhay]

Nathan,

Hi.  TextAreas not included before simply because I wasn't using them, and
overlooked them.

The tags were actually changed a little before they were added to the nightly
build, to include a "prepareIndex()" method in the BaseHandlerTag which all the
other tags now call, which makes it all a little tidier.

I'll make the adjustment for this (and RadioTag) and get them added.

Cheers,

Dave





Nathan Coast <[EMAIL PROTECTED]> on 08/22/2001
01:27:39 PM

Please respond to [EMAIL PROTECTED]

To:   "Struts-Dev (E-mail)"
  <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  dave hayes indexed properties / text area



Hi,

Sorry if this is a bit of a cross post with user but I figured dev is a
better place for this.  Is there any reason why the text area tag wasn't
included in the indexed tag patch?

We've just implemented this (copied from BaseFieldTag) in the TextAreaTag as
a workaround.
Good idea? bad idea? already done and I don't know where to find up to date
code?

public int doStartTag() throws JspException {

 // Create an appropriate "input" element based on our parameters
 StringBuffer results = new StringBuffer("

Re: JSPTL-based tags question/proposal

[dhay]

Ted,

Won't this necessitate that users are using a server that supports servlet 2.3?
Or am I missing something?

I know from the list that lots of us are using Tomcat 3.x rather than 4.  Would
we be forced to switch to 4?

Cheers,

Dave





Ted Husted <[EMAIL PROTECTED]> on 08/19/2001 10:32:22 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: JSPTL-based tags question/proposal



Once the JSPTL is finalized, I'm sure that we will revisit the Struts
tag extensions, and probably move as many as possible over to Jakarta
Taglibs, keeping only those that are too strongly tied to Struts to be
useful in another environment (e.g. the html lib).

Right now, the general feeling is that the tag extensions we have aren't
broken, and there's no point in making any drastic changes until JSPTL
is finalized.

In general, I think the Struts tags play nice with the expression
language, and can be used side by side. See

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

for an example.

Of course, if someone wanted to work on some tags in the JSPTL vien that
accessed Struts application resources, like the mappings and message
resources, I'm sure everyone would love to see the result, both here and
in Jakarta Taglibs.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/about/struts/


stuart robertson wrote:
>
> Two questions.
>
> Has anybody made a JSP 1.1 version of the jsptl?  The
> documentation mentions that this may be considered (I
> think), but I couldn't find anything in the newsgroups
> regarding this.
>
> Has anybody played with modifying Struts tags to use
> the expression language?
>
> If not, I may take a swing at both of these.
>
> The company I'm working for is looking into to start
> using custom tags rather than scriptlets.  I would
> like, if possible, for this library(ies) to be based
> on the current snapshot of the Standard Tag Library,
> using the new Expression Language.  Yes, I realize
> this isn't close to being finalized yet, but it seems
> to me that even in its current state it works and
> provides much
> more flexibility than the typical taglib designs.  I
> suspect this will be done anyway by the maintainers of
> Struts.  Any idea on the timeframe?
>
> Would anybody else be interested in working on this,
> if nobody is currently?
>
> Regards,
>
> Stuart Robertson

Problem running nightly build - org/xml/sax/helpers/DefaultHandler not found

[dhay]

Hi.

I have just built and installed the nightly build from this am -
jakarta-struts-src-20010725.zip - and am suddenly getting an error message on
tomcat startup (3.3 m2):

java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError:
org/xml/sax/helpers/DefaultHandler

Any ideas?  I checked my parser.jar and couldn't find DefaultHandler - do I need
a later version?

Cheers,

Dave

Full stack trace:

java.lang.reflect.InvocationTargetException: java.lang.NoClassDefFoundError: org
/xml/sax/helpers/DefaultHandler
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:11
1)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:553)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at org.apache.struts.action.ActionServlet.initDigester(ActionServlet.jav
a:1109)
at org.apache.struts.action.ActionServlet.initMapping(ActionServlet.java
:1265)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:459)
at beans.AppController.init(AppController.java:34)
at javax.servlet.GenericServlet.init(GenericServlet.java)
at org.apache.tomcat.facade.ServletHandler.doInit(ServletHandler.java:41
0)
at org.apache.tomcat.facade.ServletHandler.init(ServletHandler.java:265)

at org.apache.tomcat.facade.LoadOnStartupInterceptor.contextInit(LoadOnS
tartupInterceptor.java:136)
at org.apache.tomcat.core.Context.init(Context.java:537)
at org.apache.tomcat.core.ContextManager.init(ContextManager.java:531)
at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTom
cat.java:245)
at org.apache.tomcat.startup.Tomcat.start(Tomcat.java:149)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:92)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.
java:87)
at org.apache.tomcat.startup.Main.execute(Main.java:322)
at org.apache.tomcat.startup.Main.main(Main.java:189)

Re: Hot to get the iterated objects ?

[dhay]

Hi.

Have added exception handling, as below, and sent new copy of tags to Oleg to
commit.

Cheers,

Dave




Ted Husted <[EMAIL PROTECTED]> on 07/23/2001 04:41:48 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Hot to get the iterated objects ?



The Struts tags often throw exceptions, but I don't believe any write to
a log. They do record the Exception in the request context though, so it
can be reported elsewhere (e.g. an JSP error page). Here's an example
from interate:

 else {
 JspException e = new JspException
 (messages.getMessage("iterate.iterator"));
RequestUtils.saveException(pageContext, e);
throw e;
}

The messages for the exceptions are in <
taglib\logic\LocalStrings.properties >.

Sorry I could help with committing the indexed tag, but I haven't had a
chance to use it myself.


[EMAIL PROTECTED] wrote:
>
> Hi Hal,
>
> Oleg has siad he will incorporate the tag changes - just mailed him to inquire
> when he thinks this will take place (I'm on vacation for 2 weeks from this
> Friday).
>
> Am very happy to insert an exception - wasn't sure how the rest of Struts tags
> handle this type of situation.
>
> Does anyone else have a problem with throwing exception, rather than just
> writing to log?
>
> Cheers,
>
> Dave
>
> "Deadman, Hal" <[EMAIL PROTECTED]> on 07/23/2001
> 01:14:00 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   "'Struts Dev List'"
<[EMAIL PROTECTED]>
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  RE: Hot to get the iterated objects ?
>
> I am looking forward to the seeing indexed tags in the nightly build. Has a
> commiter signed up to incorporate the indexed tag changes?
>
> As for feedback on the code, I don't think it's appropriate to blow off the
> whole tag without comment if the tag with indexed="true" is not nested in an
> iterate tag. I think an exception should be thrown instead. If an exception
> isn't thrown then something needs to be written to the log file.
>
> change:
>   IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
> IterateTag.class);
>   if (iterateTag == null)
>   {
>  // this tag should only be nested in iteratetag, if it's not, don't
> do anything
>  return EVAL_PAGE;
>   }
>
> to:
>   IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
> IterateTag.class);
>   if (iterateTag == null)
>   {
>  // this tag must only be nested in an IterateTag when indexed
> attribute is "true"
> throw new JspException(messages.getMessage("some.messagekey");
>   }

RE: Hot to get the iterated objects ?

[dhay]

Hi Hal,

Oleg has siad he will incorporate the tag changes - just mailed him to inquire
when he thinks this will take place (I'm on vacation for 2 weeks from this
Friday).

Am very happy to insert an exception - wasn't sure how the rest of Struts tags
handle this type of situation.

Does anyone else have a problem with throwing exception, rather than just
writing to log?

Cheers,

Dave





"Deadman, Hal" <[EMAIL PROTECTED]> on 07/23/2001
01:14:00 PM

Please respond to [EMAIL PROTECTED]

To:   "'Struts Dev List'" <[EMAIL PROTECTED]>
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  RE: Hot to get the iterated objects ?



I am looking forward to the seeing indexed tags in the nightly build. Has a
commiter signed up to incorporate the indexed tag changes?

As for feedback on the code, I don't think it's appropriate to blow off the
whole tag without comment if the tag with indexed="true" is not nested in an
iterate tag. I think an exception should be thrown instead. If an exception
isn't thrown then something needs to be written to the log file.

change:
  IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
  if (iterateTag == null)
  {
 // this tag should only be nested in iteratetag, if it's not, don't
do anything
 return EVAL_PAGE;
  }

to:
  IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
  if (iterateTag == null)
  {
 // this tag must only be nested in an IterateTag when indexed
attribute is "true"
throw new JspException(messages.getMessage("some.messagekey");
  }



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 3:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Hot to get the iterated objects ?




Hi Prashanth,

Just posted an example of how to do this, using the indexed tags (see
http://husted.com/about/struts/indexed-tags.htm).

Note:  these should be in the nightly build fairly soon!!

Cheers,

Dave





Prashanth_Thm <[EMAIL PROTECTED]> on 07/19/2001
10:38:57 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Hot to get the iterated objects ?



Hi,
 I am new to struts.
 I have a summary of rows(contains text boxes also) to be
displayed...which i am able
 to display using the "logic:iterate" tag like this:
 

 But now i have to get the values entered in the rowswhen submit
is clicked.
 how do i do that?

 Your help is appreciated !

Thanks,
Prashanth.

servlet-class specification in web.xml - '/' or '.' separator?

[dhay]

Hi everyone.

Was wondering if anyone knows whether you should use a '/' or a '.' as the
package separator in classes specified in web.xml?  eg for my precompiled Jsp's:

   

changeLogFileName


JspServ/changeLogFileName

   

or

   

changeLogFileName


JspServ.changeLogFileName

   

I inherited some code which uses /'s, and this works fine on all platforms,
except AIX!  I submitted a bug (tomcat), and was told that the classes must be
specified using '.'.

Does anyone familiar with the spec (Craig?) know if this is true?  I checked out
the spec and couldn't find it in there.

Cheers,

Dave

Re: Struts v1.0.1

[dhay]

Hi Ted.  If they are added to the 1.1 tree, will they make it into the nightly
build?  Would be great to have them in there so people don't have to keep
copying them into the latest source and rebuilding.

Cheers,

Dave





Ted Husted <[EMAIL PROTECTED]> on 07/16/2001 12:20:13 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Struts v1.0.1



Personally, I would call this a new feature, and so appropriate for the
1.1 nightly-build branch but not the 1.0.x fixes-only branch.

I haven't had a chance to test these changes myself, but if Martin or
Oleg wanted to commit them to the 1.1 tree, I would have no objection.

[EMAIL PROTECTED] wrote:
>
> Is there someone that could commit the code I posted for the indexed tags
> (http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg02461.html)?
>
> Would be great to have them in the 1.01 release.

Re: Struts v1.0.1

[dhay]

Is there someone that could commit the code I posted for the indexed tags
(http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg02461.html)?

Would be great to have them in the 1.01 release.

Thanks,

Dave





Ted Husted <[EMAIL PROTECTED]> on 07/16/2001 08:11:27 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Struts v1.0.1



A 1.01 release has been planned, but a date has not been set.

I would suggest that we publish 1.01 on July 31st with the fixes to
date.

Chris Miller wrote:
> Just wondering if/when we're likely to see a point release for Struts v1.0
> that includes the latest bug fixes etc? Are there still bugs outstanding, or
> is it more a case of waiting for a certain period of time to pass with no
> new bugs being reported?
>
> At the moment we've got the patch in place for the file upload bug, but it
> would obviously be nicer for deployment to be using a 'real' version of
> Struts.
>
> Regards,
> Chris Miller

Indexed tags to be committed...

[dhay]

Hi everyone,

Please find attached latest version of tags.  As mentioned below, the link tag
will create an extra parameter in the link if "indexed=true" is specified.
Default is for this parameter to be named 'index', but this can be changed by
specifying "indexId=myParamName" to change it.

If everyone is in agreement, please could someone commit the attached code?  I
have made the changes against the 1.0 release version of tags (don't know if
anyone has made any other changes to these files since then?).

Cheers,

Dave

PS  What about changes to documentation?  Do I need to write something for
these?

(See attached file: struts indexed files.ZIP)




David Hay
07/11/2001 10:44 AM

To:   [EMAIL PROTECTED]
cc:

Subject:  Re: Re[2]: Indexed tags - proposal to add changes  (Document link:
  David Hay)

Hi Martin,

Good point.  But I would lean towards leaving the "indexed=true" to make it the
same as all the other tags, and make the "indexId=..." as optional ie default to
naming the parameter we add "index" which they can change using
"indexId=myParamName" if they want to.

If no-one has objections, I will go ahead and do this, and post the code to the
list.

Cheers,

Dave




"Martin Cooper" <[EMAIL PROTECTED]> on
07/11/2001 12:56:45 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Re[2]: Indexed tags - proposal to add changes



Thinking about this some more, if we have the 'indexId' attribute, do we
need the 'indexed' attribute as well? Wouldn't the specification of a value
for 'indexId' imply 'indexed="true"' anyway?

--
Martin Cooper


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 1:07 PM
Subject: Re: Re[2]: Indexed tags - proposal to add changes


>
>
> Have changed the LinkTag to allow users to specify the indexId.
>
> After doing some more investigation, don't think your first suggestion,
Oleg,
> would ever come up.  If the user specifies the paramName, Id and property
in a
> link in a particular row in the table ie in your example:
>
> >  > paramId="whenSell" includeIndex="yes">
>
> I believe the user will expect to simply see the sell.when value for that
> iteration, which is what the current tag will do!  Thus the includeIndex
(or
> index=true), if this is their intention, is not necessary at all.
>
> So...suggest that the only usage required will be:
>
> 
>...
> paramProperty="value" indexed="true" indexId="recordNo">a
>...
> 
>
> which would produce (for the first iteration) the following link:
>
> a
>
> One question for you all - do we want to default the indexId to something
(eg
> "index=") or do I throw an exception if index="true" is specified without
> indexId?
>
> Should then be ready to submit code...
>
> Cheers,
>
> Dave
>
>
>
>
>
> "Martin Cooper" <[EMAIL PROTECTED]> on
> 07/10/2001 12:28:40 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   [EMAIL PROTECTED]
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: Re[2]: Indexed tags - proposal to add changes
>
>
>
> +1 for 'indexed="true"'
>
> +1 for 'indexId'
>
> --
> Martin Cooper
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Oleg V Alexeev" <[EMAIL PROTECTED]>
> Sent: Monday, July 09, 2001 9:35 AM
> Subject: Re: Re[2]: Indexed tags - proposal to add changes
>
>
> >
> >
> > Hi.  Does anyone have any comments on this?  Personally I would opt for
> leaving
> > includeIndex="yes" as indexed="true" to match other syntax.
> >
> > But, do we want to provide both types of indexed links?
> >
> > Cheers,
> >
> > Dave
> >
> >
> >
> >
> >
> > Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001
> 02:03:25 AM
> >
> > Please respond to [EMAIL PROTECTED];
> Please
> >   respond to Oleg V Alexeev <[EMAIL PROTECTED]>
> >
> > To:   [EMAIL PROTECTED]
> > cc:(bcc: David Hay/Lex/Lexmark)
> > Subject:  Re[2]: Indexed tags - proposal to add changes
> >
> >
> >
> > Hello dhay,
> >
> > Link tag must build name of some parameter on base of index value or
> > use it as separate parameter (I agree with you... 8) )
> >
> >  > paramId="whenSell" includeIndex="yes">
> >
> > with result as - htt

Re: Re[2]: Indexed tags - proposal to add changes

[dhay]

Hi Martin,

Good point.  But I would lean towards leaving the "indexed=true" to make it the
same as all the other tags, and make the "indexId=..." as optional ie default to
naming the parameter we add "index" which they can change using
"indexId=myParamName" if they want to.

If no-one has objections, I will go ahead and do this, and post the code to the
list.

Cheers,

Dave





"Martin Cooper" <[EMAIL PROTECTED]> on
07/11/2001 12:56:45 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Re[2]: Indexed tags - proposal to add changes



Thinking about this some more, if we have the 'indexId' attribute, do we
need the 'indexed' attribute as well? Wouldn't the specification of a value
for 'indexId' imply 'indexed="true"' anyway?

--
Martin Cooper


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 1:07 PM
Subject: Re: Re[2]: Indexed tags - proposal to add changes


>
>
> Have changed the LinkTag to allow users to specify the indexId.
>
> After doing some more investigation, don't think your first suggestion,
Oleg,
> would ever come up.  If the user specifies the paramName, Id and property
in a
> link in a particular row in the table ie in your example:
>
> >  > paramId="whenSell" includeIndex="yes">
>
> I believe the user will expect to simply see the sell.when value for that
> iteration, which is what the current tag will do!  Thus the includeIndex
(or
> index=true), if this is their intention, is not necessary at all.
>
> So...suggest that the only usage required will be:
>
> 
>...
> paramProperty="value" indexed="true" indexId="recordNo">a
>...
> 
>
> which would produce (for the first iteration) the following link:
>
> a
>
> One question for you all - do we want to default the indexId to something
(eg
> "index=") or do I throw an exception if index="true" is specified without
> indexId?
>
> Should then be ready to submit code...
>
> Cheers,
>
> Dave
>
>
>
>
>
> "Martin Cooper" <[EMAIL PROTECTED]> on
> 07/10/2001 12:28:40 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   [EMAIL PROTECTED]
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: Re[2]: Indexed tags - proposal to add changes
>
>
>
> +1 for 'indexed="true"'
>
> +1 for 'indexId'
>
> --
> Martin Cooper
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Oleg V Alexeev" <[EMAIL PROTECTED]>
> Sent: Monday, July 09, 2001 9:35 AM
> Subject: Re: Re[2]: Indexed tags - proposal to add changes
>
>
> >
> >
> > Hi.  Does anyone have any comments on this?  Personally I would opt for
> leaving
> > includeIndex="yes" as indexed="true" to match other syntax.
> >
> > But, do we want to provide both types of indexed links?
> >
> > Cheers,
> >
> > Dave
> >
> >
> >
> >
> >
> > Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001
> 02:03:25 AM
> >
> > Please respond to [EMAIL PROTECTED];
> Please
> >   respond to Oleg V Alexeev <[EMAIL PROTECTED]>
> >
> > To:   [EMAIL PROTECTED]
> > cc:(bcc: David Hay/Lex/Lexmark)
> > Subject:  Re[2]: Indexed tags - proposal to add changes
> >
> >
> >
> > Hello dhay,
> >
> > Link tag must build name of some parameter on base of index value or
> > use it as separate parameter (I agree with you... 8) )
> >
> >  > paramId="whenSell" includeIndex="yes">
> >
> > with result as - http://.../news.do?whenSell=today[30]
> >
> > Or
> >
> >  > includeIndex="yes" indexId="myIndex">
> >
> > with result as - http://.../news.do?id=2&myIndex=30
> >
> > Friday, July 06, 2001, 10:10:33 PM, you wrote:
> >
> >
> >
> > dlc> Oleg,
> >
> > dlc> Hi.  Agree that the link tag is different, but think that it is due
> to its
> > dlc> nature!  Unlike the other tags, adding index as a query param seems
> to me
> > the
> > dlc> only reasonable way to provide access to the index in the link.
Not
> sure
> > how
> > dlc> else to do it (if you try and use name, obviously you change the
link
> into
> > an
> > dlc> anchor!).
> >
> > dlc> If you (or any

Re: Re[2]: Indexed tags - proposal to add changes

[dhay]

Have changed the LinkTag to allow users to specify the indexId.

After doing some more investigation, don't think your first suggestion, Oleg,
would ever come up.  If the user specifies the paramName, Id and property in a
link in a particular row in the table ie in your example:

>  paramId="whenSell" includeIndex="yes">

I believe the user will expect to simply see the sell.when value for that
iteration, which is what the current tag will do!  Thus the includeIndex (or
index=true), if this is their intention, is not necessary at all.

So...suggest that the only usage required will be:


   ...
   a
   ...


which would produce (for the first iteration) the following link:

a

One question for you all - do we want to default the indexId to something (eg
"index=") or do I throw an exception if index="true" is specified without
indexId?

Should then be ready to submit code...

Cheers,

Dave





"Martin Cooper" <[EMAIL PROTECTED]> on
07/10/2001 12:28:40 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Re[2]: Indexed tags - proposal to add changes



+1 for 'indexed="true"'

+1 for 'indexId'

--
Martin Cooper


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Oleg V Alexeev" <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 9:35 AM
Subject: Re: Re[2]: Indexed tags - proposal to add changes


>
>
> Hi.  Does anyone have any comments on this?  Personally I would opt for
leaving
> includeIndex="yes" as indexed="true" to match other syntax.
>
> But, do we want to provide both types of indexed links?
>
> Cheers,
>
> Dave
>
>
>
>
>
> Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001
02:03:25 AM
>
> Please respond to [EMAIL PROTECTED];
Please
>   respond to Oleg V Alexeev <[EMAIL PROTECTED]>
>
> To:   [EMAIL PROTECTED]
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re[2]: Indexed tags - proposal to add changes
>
>
>
> Hello dhay,
>
> Link tag must build name of some parameter on base of index value or
> use it as separate parameter (I agree with you... 8) )
>
>  paramId="whenSell" includeIndex="yes">
>
> with result as - http://.../news.do?whenSell=today[30]
>
> Or
>
>  includeIndex="yes" indexId="myIndex">
>
> with result as - http://.../news.do?id=2&myIndex=30
>
> Friday, July 06, 2001, 10:10:33 PM, you wrote:
>
>
>
> dlc> Oleg,
>
> dlc> Hi.  Agree that the link tag is different, but think that it is due
to its
> dlc> nature!  Unlike the other tags, adding index as a query param seems
to me
> the
> dlc> only reasonable way to provide access to the index in the link.  Not
sure
> how
> dlc> else to do it (if you try and use name, obviously you change the link
into
> an
> dlc> anchor!).
>
> dlc> If you (or anyone else) has any suggestions to handle it in a better
way
> would
> dlc> like to hear them - maybe I missed something!
>
> dlc> Cheers,
>
> dlc> Dave
>
>
>
>
>
> dlc> Oleg V Alexeev <[EMAIL PROTECTED]> on 07/06/2001
> 01:47:47 PM
>
> dlc> Please respond to
[EMAIL PROTECTED];
> Please
> dlc>   respond to Oleg V Alexeev
<[EMAIL PROTECTED]>
>
> dlc> To:   [EMAIL PROTECTED]
> dlc> cc:(bcc: David Hay/Lex/Lexmark)
> dlc> Subject:  Re: Indexed tags - proposal to add changes
>
>
>
> dlc> Hello dhay,
>
> dlc> I think it useful addition with minimal changes of existing code -
> dlc> good solution. But there is one problem for my mind - html:link with
> dlc> index=x. All another tag proposals are simple and transparent.
>
> dlc> Friday, July 06, 2001, 9:31:21 PM, you wrote:
>
>
>
> dlc>> Hi everyone.
>
> dlc>> I have been posting to the user list for some time now regarding
creating
> dlc>> indexed names within an iterate tag.   From feedback from that list,
this
> dlc> seems
> dlc>> to be an important addition to the current tags.
>
> dlc>> While looking to write my own additional tags which would do this
(eg
> dlc>> html:indexedText etc), I discovered that this functionality could
easily
> be
> dlc>> added to the current tags, now that the getIndex() method is
available, by
> dlc>> creating an extra parameter 'indexed' which when set to true would
create
> dlc> the
> dlc>> indexed names.  The necessary additions to current code were small
and
> dlc> quite
> dlc>> clean, as follows:
>
> dlc>> - added 'indexed' as a 

Re: Re[2]: Indexed tags - proposal to add changes

[dhay]

Hi.  Does anyone have any comments on this?  Personally I would opt for leaving
includeIndex="yes" as indexed="true" to match other syntax.

But, do we want to provide both types of indexed links?

Cheers,

Dave





Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001 02:03:25 AM

Please respond to [EMAIL PROTECTED]; Please
  respond to Oleg V Alexeev <[EMAIL PROTECTED]>

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re[2]: Indexed tags - proposal to add changes



Hello dhay,

Link tag must build name of some parameter on base of index value or
use it as separate parameter (I agree with you... 8) )



with result as - http://.../news.do?whenSell=today[30]

Or



with result as - http://.../news.do?id=2&myIndex=30

Friday, July 06, 2001, 10:10:33 PM, you wrote:



dlc> Oleg,

dlc> Hi.  Agree that the link tag is different, but think that it is due to its
dlc> nature!  Unlike the other tags, adding index as a query param seems to me
the
dlc> only reasonable way to provide access to the index in the link.  Not sure
how
dlc> else to do it (if you try and use name, obviously you change the link into
an
dlc> anchor!).

dlc> If you (or anyone else) has any suggestions to handle it in a better way
would
dlc> like to hear them - maybe I missed something!

dlc> Cheers,

dlc> Dave





dlc> Oleg V Alexeev <[EMAIL PROTECTED]> on 07/06/2001
01:47:47 PM

dlc> Please respond to [EMAIL PROTECTED];
Please
dlc>   respond to Oleg V Alexeev <[EMAIL PROTECTED]>

dlc> To:   [EMAIL PROTECTED]
dlc> cc:(bcc: David Hay/Lex/Lexmark)
dlc> Subject:  Re: Indexed tags - proposal to add changes



dlc> Hello dhay,

dlc> I think it useful addition with minimal changes of existing code -
dlc> good solution. But there is one problem for my mind - html:link with
dlc> index=x. All another tag proposals are simple and transparent.

dlc> Friday, July 06, 2001, 9:31:21 PM, you wrote:



dlc>> Hi everyone.

dlc>> I have been posting to the user list for some time now regarding creating
dlc>> indexed names within an iterate tag.   From feedback from that list, this
dlc> seems
dlc>> to be an important addition to the current tags.

dlc>> While looking to write my own additional tags which would do this (eg
dlc>> html:indexedText etc), I discovered that this functionality could easily
be
dlc>> added to the current tags, now that the getIndex() method is available, by
dlc>> creating an extra parameter 'indexed' which when set to true would create
dlc> the
dlc>> indexed names.  The necessary additions to current code were small and
dlc> quite
dlc>> clean, as follows:

dlc>> - added 'indexed' as a parameter in BaseHandlerTag, with appropriate
dlc>> setter/getter
dlc>> - added if statement which checks for 'indexed=true', and if so, appends
dlc> "[x]"
dlc>> to the name, before appending property eg myProperty[x].value.
dlc>>   This was added to BaseFieldTag (to cover tags which extend this) and
dlc>> CheckBoxTag, & SelectTag
dlc>>  as follows:
dlc>>//if "indexed=true" parameter, create indexed name for this tag eg
dlc>> name="myCollection[x].myproperty"
dlc>>if ("true".equals(indexed))
dlc>>{
dlc>>   // look for outer iterate tag
dlc>>   IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
dlc>> IterateTag.class);
dlc>>   if (iterateTag == null)
dlc>>   {
dlc>>  // this tag should only be nested in iteratetag, if it's not,
dlc> don't do
dlc>> anything
dlc>>  return EVAL_PAGE;
dlc>>   }

dlc>>   results.append(getName());
dlc>>   results.append("[");
dlc>>   results.append(iterateTag.getIndex());
dlc>>   results.append("].");
dlc>>}

dlc>> - Slight variations were added to SubmitTag and ButtonTag to simply add
dlc> index to
dlc>> it's name ie mySubmit[x].
dlc>> - linkTag was somewhat different due to its nature.  I added if statement
dlc> to add
dlc>> "index=x" as a parameter to the link's querystring  ie myAction.do?index=1
dlc> or
dlc>> myAction.do?param1=37&index=1, as follows:
dlc>> //if "indexed=true", add "index=x" parameter to query string
dlc>> if ("true".equals(indexed))
dlc>> {
dlc>>// look for outer iterate tag
dlc>>IterateTag iterateTag = (IterateTag)
findAncestorWithClass(this,
dlc>> IterateTag.class);
dlc>>if (iterateTag == null)
dlc>>{
dlc>>// this tag sh

Re: Indexed tags - proposal to add changes

[dhay]

Oleg,

Hi.  Agree that the link tag is different, but think that it is due to its
nature!  Unlike the other tags, adding index as a query param seems to me the
only reasonable way to provide access to the index in the link.  Not sure how
else to do it (if you try and use name, obviously you change the link into an
anchor!).

If you (or anyone else) has any suggestions to handle it in a better way would
like to hear them - maybe I missed something!

Cheers,

Dave





Oleg V Alexeev <[EMAIL PROTECTED]> on 07/06/2001 01:47:47 PM

Please respond to [EMAIL PROTECTED]; Please
  respond to Oleg V Alexeev <[EMAIL PROTECTED]>

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Indexed tags - proposal to add changes



Hello dhay,

I think it useful addition with minimal changes of existing code -
good solution. But there is one problem for my mind - html:link with
index=x. All another tag proposals are simple and transparent.

Friday, July 06, 2001, 9:31:21 PM, you wrote:



dlc> Hi everyone.

dlc> I have been posting to the user list for some time now regarding creating
dlc> indexed names within an iterate tag.   From feedback from that list, this
seems
dlc> to be an important addition to the current tags.

dlc> While looking to write my own additional tags which would do this (eg
dlc> html:indexedText etc), I discovered that this functionality could easily be
dlc> added to the current tags, now that the getIndex() method is available, by
dlc> creating an extra parameter 'indexed' which when set to true would create
the
dlc> indexed names.  The necessary additions to current code were small and
quite
dlc> clean, as follows:

dlc> - added 'indexed' as a parameter in BaseHandlerTag, with appropriate
dlc> setter/getter
dlc> - added if statement which checks for 'indexed=true', and if so, appends
"[x]"
dlc> to the name, before appending property eg myProperty[x].value.
dlc>   This was added to BaseFieldTag (to cover tags which extend this) and
dlc> CheckBoxTag, & SelectTag
dlc>  as follows:
dlc>//if "indexed=true" parameter, create indexed name for this tag eg
dlc> name="myCollection[x].myproperty"
dlc>if ("true".equals(indexed))
dlc>{
dlc>   // look for outer iterate tag
dlc>   IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
dlc> IterateTag.class);
dlc>   if (iterateTag == null)
dlc>   {
dlc>  // this tag should only be nested in iteratetag, if it's not,
don't do
dlc> anything
dlc>  return EVAL_PAGE;
dlc>   }

dlc>   results.append(getName());
dlc>   results.append("[");
dlc>   results.append(iterateTag.getIndex());
dlc>   results.append("].");
dlc>}

dlc> - Slight variations were added to SubmitTag and ButtonTag to simply add
index to
dlc> it's name ie mySubmit[x].
dlc> - linkTag was somewhat different due to its nature.  I added if statement
to add
dlc> "index=x" as a parameter to the link's querystring  ie myAction.do?index=1
or
dlc> myAction.do?param1=37&index=1, as follows:
dlc> //if "indexed=true", add "index=x" parameter to query string
dlc> if ("true".equals(indexed))
dlc> {
dlc>// look for outer iterate tag
dlc>IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
dlc> IterateTag.class);
dlc>if (iterateTag == null)
dlc>{
dlc>// this tag should only be nested in iteratetag, if it's
not,
dlc> don't do anything
dlc>   System.out.println("couldn't find enclosing iterate tag");
dlc>   return EVAL_PAGE;
dlc>}

dlc>//calculate index, and add as a parameter
dlc>if (params == null)
dlc>{
dlc>params = new HashMap(); //create new HashMap if
no
dlc> other params
dlc>}
dlc>params.put("index", "" + iterateTag.getIndex());
dlc> }
dlc> - minimal changes to struts-html.tld to add 'indexed' as param.

dlc> All of this code has been available at Ted's site for a while, and I would
like
dlc> to suggest it is added to the Struts source.  Numerous people are already
using
dlc> it, and I believe many more would if it was part of the build.

dlc> Would appreciate your feedback, and not sure what happens next (just joined
this
dlc> list)!

dlc> Cheers,

dlc> Dave

dlc> PS  code attached(See attached file: struts indexed files.ZIP)






--
Best regards,
 Olegmailto:[EMAIL PROTECTED]

Indexed tags - proposal to add changes

[dhay]

Hi everyone.

I have been posting to the user list for some time now regarding creating
indexed names within an iterate tag.   From feedback from that list, this seems
to be an important addition to the current tags.

While looking to write my own additional tags which would do this (eg
html:indexedText etc), I discovered that this functionality could easily be
added to the current tags, now that the getIndex() method is available, by
creating an extra parameter 'indexed' which when set to true would create the
indexed names.  The necessary additions to current code were small and quite
clean, as follows:

- added 'indexed' as a parameter in BaseHandlerTag, with appropriate
setter/getter
- added if statement which checks for 'indexed=true', and if so, appends "[x]"
to the name, before appending property eg myProperty[x].value.
  This was added to BaseFieldTag (to cover tags which extend this) and
CheckBoxTag, & SelectTag
 as follows:
   //if "indexed=true" parameter, create indexed name for this tag eg
name="myCollection[x].myproperty"
   if ("true".equals(indexed))
   {
  // look for outer iterate tag
  IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
  if (iterateTag == null)
  {
 // this tag should only be nested in iteratetag, if it's not, don't do
anything
 return EVAL_PAGE;
  }

  results.append(getName());
  results.append("[");
  results.append(iterateTag.getIndex());
  results.append("].");
   }

- Slight variations were added to SubmitTag and ButtonTag to simply add index to
it's name ie mySubmit[x].
- linkTag was somewhat different due to its nature.  I added if statement to add
"index=x" as a parameter to the link's querystring  ie myAction.do?index=1 or
myAction.do?param1=37&index=1, as follows:
//if "indexed=true", add "index=x" parameter to query string
if ("true".equals(indexed))
{
   // look for outer iterate tag
   IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
   if (iterateTag == null)
   {
   // this tag should only be nested in iteratetag, if it's not,
don't do anything
  System.out.println("couldn't find enclosing iterate tag");
  return EVAL_PAGE;
   }

   //calculate index, and add as a parameter
   if (params == null)
   {
   params = new HashMap(); //create new HashMap if no
other params
   }
   params.put("index", "" + iterateTag.getIndex());
}
- minimal changes to struts-html.tld to add 'indexed' as param.

All of this code has been available at Ted's site for a while, and I would like
to suggest it is added to the Struts source.  Numerous people are already using
it, and I believe many more would if it was part of the build.

Would appreciate your feedback, and not sure what happens next (just joined this
list)!

Cheers,

Dave

PS  code attached(See attached file: struts indexed files.ZIP)




 .ZIP File