RE: href=/Struts/testing.do?action=ADDuserid=1234#top

[James Mitchell]

Huh?

All text after a # is interpreted as an anchor and the web browser will
scroll (or ignore, if not there) accordingly.

Unless you plan to place a name=#top on all jsp pages that you can
forward to for this action, and NOT use the base tag, then this won't matter
(and will be ignored for ).

You still have not said (in English) what you are trying to do.  Why are you
needing to go the #top?
Are you trying to force the browser to scroll instead of jump to the link?
(If yes, then just use a href=#top instead of html:link
href=/testing.do?action=ADDuserid=1234#top)



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


 -Original Message-
 From: Ng, Paul Y [mailto:paul.ng;eds.com]
 Sent: Friday, October 25, 2002 1:52 AM
 To: 'Struts Developers List'
 Subject: RE: href=/Struts/testing.do?action=ADDuserid=1234#top


 Hi,

 I would like to be able to write out the following URL

 href=localhost:8080/testing.do?action=ADDuserid=1234status=A#top
 href=localhost:8080/testing.do?action=ADDuserid=1234
 href=localhost:8080/testing.do?action=ADDuserid=1234#top

 Is it correct to say that I should do something like this

 app:linkUser page=/testingdo?action=ADD
   bean:write name=user property=userid filter=true/
   bean:write name=user property=top filter=true/
 /app:linkUser

 where property top is actually #top?

 And in the doStartTag() method have

 public int doStartTag() throws JspException {
   url.append();
   url.append(userid=);
   url.append(ResponseUtils.filter(  user.getUserid() ));
   url.append(ResponseUtils.filter(  user.getTop() ));
 }

 Thanks,
 Paul Ng


 -Original Message-
 From: James Mitchell [mailto:jmitchtx;telocity.com]
 Sent: Friday, October 25, 2002 11:51 AM
 To: Struts Developers List
 Subject: RE: href=/Struts/testing.do?action=ADDuserid=1234#top


 '#top' will only be there if you tell it to.

 Could you explain a bit further what you are wanting to do?


 James Mitchell
 Software Engineer/Struts Evangelist
 http://www.open-tools.org

 Only two things are infinite, the universe and human stupidity,
 and I'm not
 sure about the former.
 - Albert Einstein (1879-1955)


  -Original Message-
  From: Ng, Paul Y [mailto:paul.ng;eds.com]
  Sent: Thursday, October 24, 2002 11:21 PM
  To: 'Struts Developers List'
  Subject: href=/Struts/testing.do?action=ADDuserid=1234#top
 
 
  Hi there,
 
  I would like to use a custom tag and Struts bean to write out the
  following
  URL.
 
  href=/Struts/testing.do?action=ADDuserid=1234#top
 
  My question is,
  is it possible to make the custom tag generic so that it
 doesn't write out
  the hash mark #top on some JSPs?
 
 
  Thanks,
  Paul Ng
 
  --
  To unsubscribe, e-mail:
  mailto:struts-dev-unsubscribe;jakarta.apache.org
  For additional commands, e-mail:
  mailto:struts-dev-help;jakarta.apache.org
 
 


 --
 To unsubscribe, e-mail:
 mailto:struts-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:struts-dev-help;jakarta.apache.org

 --
 To unsubscribe, e-mail:
 mailto:struts-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:struts-dev-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Committed

[James Mitchell]

Well, some say I should be, but that's another story!!!

I made a small change to a file over 2 hours ago, and (unless I missed it)
never received a copy of the commit.
Just wondering if there is a problem with my account.

The file I modified was jakarta-struts/web/blank/index.asp  Just kidding, it
was STATUS



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: HTML formatting of newline characters with bean:write tag

[Inge Solvoll]

I agree with you on most of this. I can clearly see that it is hard to draw 
the line when to stop filtering in the bean:write tag and other tags and 
leave this to other taglibs.

The current filter functionality that escapes html is also basically 
functionality that could have been done by some tag in JSTL. But for 
functionality that is very common, I think it is reasonable to focus on 
convenience rather than design principles.

If you agree with this, the interesting discussion here then is:
- What is the more common case when outputting text with the bean:write 
tag? To view the text with visible linefeeds as inputted by the user, or not?
- Are there other filtering tasks that are equally common as this? If there 
are, it would be less reasonable to insert linefeed filtering, as you said, 
as it would cause a storm of filtering requests...
- Is the need for filtering linefeeds as common as I think? Or is my webapp 
an edge case?
- Are there other Struts tag that this discussion applies to?

At 17:41 24.10.2002 -0400, you wrote:
IMHO, once we opened the door past the filter
attribute, people would suggest that we start
adding this or that to the bean write tag as well.

I would say that any transformations beyond the
escape filter really belong on some other tag.

IMHO, a better place for a tag like this is
Taglibs. This functionality does not involve the
core framework directly, and the effort may get
more exposure in taglibs than here.

Also, IMHO, we should encourage people to look to
Taglibs for general-purpose tags. Post 1.1, we
might seriously consider migrating the bean,
logic, tile, and template packages to Taglibs (if
they will have them), where it can stand toe-to-
toe with JSTL.

This would let us focus on the HTML tags that
interact with the framework, and leave the generic
functionality to the (other) Jakarta community
that specializes in such things.

But if someone supplies the patch, and a Committer
applies it, like Craig, I'm +0 on the deal.

-Ted.

10/24/2002 5:12:19 AM, Inge Solvoll
[EMAIL PROTECTED] wrote:

I actually didn't think of creating a tag that
can be wrapped around the
bean:write tag, that's obviously the best
solution for me. I'll check if
there is something like that in Jakarta taglib. I
believe someone here
mentioned a 'replace' tag.

But, for me this is still an interesting
question. The web application I'm
working on is very big and has a lot of text
input and output. All of our
inputted text should preserve linebreaks. Text
entered in regular text
fields doesn't have linebreaks anyway, and text
from textareas should have
breaks. I see that it isn't too pretty code to
always insert BR-tags in
bean:write, but couldn't this at least be an
option, like this:

bean:write name=myBean property=myProp
preserveLineFeed=false,

where preserveLineFeed would be true by default?
The tag would then use a
method like the breakNewlines(String) method
suggested below.

For my web application this would be far more
elegant than wrapping another
custom tag around every single bean:write that
needs to preserve line
breaks. As I said, the need to preserve
linebreaks is very common in my
experience, I rarely want to NOT preserve
linebreaks... At least for me
because most of the text that is outputted is
text inputted by a user in a
textfield or textarea.

The bean:write tag already has an attribute
filter that escapes
HTML-formatting, which in my opinion covers the
same kind of thing, how the
output looks when rendered in html, why is it not
elegant to do the same
thing for linebreaks?

At 12:02 23.10.2002 -0500, you wrote:
There are already taglibs that do this
transformation, aren't there?
Doesn't the taglibs project have things that
address this?  Is there a way
to do this using the JSTL (Martin?)?

David Graham wrote:

If this is a common problem, maybe we could add
a method to Action like
breakNewLines(String) that does this
transformation.  The bean:write
tag should not do any transformation, just
display what it's given.

What do you think?

Dave


--
Eddie Bush




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


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








--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: href=/Struts/testing.do?action=ADDuserid=1234#top

[Ng, Paul Y]

Thanks for the tip.  The html:link tag works for me!

Sorry I wasn't clear in my earlier email.
I'm testing/evaluating Struts at the moment.
I created a data-entry form to do Create/Update/Delete actions.  
All the actions are processed by an action class and forwarded to
the same JSP.

Therefore, I need to have different links such as

html:link href=/testing.do?action=ADD#top for Create action
html:link href=/testing.do?action=UPDATEuserid=1234#top for
Update/Delete action.

Thanks,
Paul Ng


-Original Message-
From: James Mitchell [mailto:jmitchtx;telocity.com]
Sent: Friday, October 25, 2002 2:23 PM
To: Struts Developers List
Subject: RE: href=/Struts/testing.do?action=ADDuserid=1234#top


Huh?

All text after a # is interpreted as an anchor and the web browser will
scroll (or ignore, if not there) accordingly.

Unless you plan to place a name=#top on all jsp pages that you can
forward to for this action, and NOT use the base tag, then this won't matter
(and will be ignored for ).

You still have not said (in English) what you are trying to do.  Why are you
needing to go the #top?
Are you trying to force the browser to scroll instead of jump to the link?
(If yes, then just use a href=#top instead of html:link
href=/testing.do?action=ADDuserid=1234#top)



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


 -Original Message-
 From: Ng, Paul Y [mailto:paul.ng;eds.com]
 Sent: Friday, October 25, 2002 1:52 AM
 To: 'Struts Developers List'
 Subject: RE: href=/Struts/testing.do?action=ADDuserid=1234#top


 Hi,

 I would like to be able to write out the following URL

 href=localhost:8080/testing.do?action=ADDuserid=1234status=A#top
 href=localhost:8080/testing.do?action=ADDuserid=1234
 href=localhost:8080/testing.do?action=ADDuserid=1234#top

 Is it correct to say that I should do something like this

 app:linkUser page=/testingdo?action=ADD
   bean:write name=user property=userid filter=true/
   bean:write name=user property=top filter=true/
 /app:linkUser

 where property top is actually #top?

 And in the doStartTag() method have

 public int doStartTag() throws JspException {
   url.append();
   url.append(userid=);
   url.append(ResponseUtils.filter(  user.getUserid() ));
   url.append(ResponseUtils.filter(  user.getTop() ));
 }

 Thanks,
 Paul Ng


 -Original Message-
 From: James Mitchell [mailto:jmitchtx;telocity.com]
 Sent: Friday, October 25, 2002 11:51 AM
 To: Struts Developers List
 Subject: RE: href=/Struts/testing.do?action=ADDuserid=1234#top


 '#top' will only be there if you tell it to.

 Could you explain a bit further what you are wanting to do?


 James Mitchell
 Software Engineer/Struts Evangelist
 http://www.open-tools.org

 Only two things are infinite, the universe and human stupidity,
 and I'm not
 sure about the former.
 - Albert Einstein (1879-1955)


  -Original Message-
  From: Ng, Paul Y [mailto:paul.ng;eds.com]
  Sent: Thursday, October 24, 2002 11:21 PM
  To: 'Struts Developers List'
  Subject: href=/Struts/testing.do?action=ADDuserid=1234#top
 
 
  Hi there,
 
  I would like to use a custom tag and Struts bean to write out the
  following
  URL.
 
  href=/Struts/testing.do?action=ADDuserid=1234#top
 
  My question is,
  is it possible to make the custom tag generic so that it
 doesn't write out
  the hash mark #top on some JSPs?
 
 
  Thanks,
  Paul Ng
 
  --
  To unsubscribe, e-mail:
  mailto:struts-dev-unsubscribe;jakarta.apache.org
  For additional commands, e-mail:
  mailto:struts-dev-help;jakarta.apache.org
 
 


 --
 To unsubscribe, e-mail:
 mailto:struts-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:struts-dev-help;jakarta.apache.org

 --
 To unsubscribe, e-mail:
 mailto:struts-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail:
 mailto:struts-dev-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts STATUS

[jmitchell]

jmitchell2002/10/24 20:41:23

  Modified:.STATUS
  Log:
  12 Bugs listed here (Is this being maintained?)
  
  Revision  ChangesPath
  1.61  +2 -2  jakarta-struts/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/jakarta-struts/STATUS,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- STATUS20 Oct 2002 18:14:56 -  1.60
  +++ STATUS25 Oct 2002 03:41:23 -  1.61
   -6,7 +6,7 
   OUTSTANDING BUGS IN STRUTS 1.1-b2 AND NIGHTLY BUILDS
   
   
  -20 open bugs to swat!!
  +12 open bugs to swat!!
   
   
   Controller:
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Committed

[Ted Husted]

A list moderator has to pass the first one through, so it knows 
you're kosher.

10/25/2002 2:25:43 AM, James Mitchell [EMAIL PROTECTED] 
wrote:

Well, some say I should be, but that's another story!!!

I made a small change to a file over 2 hours ago, and (unless 
I missed it)
never received a copy of the commit.
Just wondering if there is a problem with my account.

The file I modified was jakarta-struts/web/blank/index.asp  
Just kidding, it
was STATUS



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human 
stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


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






--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: HTML formatting of newline characters with bean:write tag

[Ted Husted]

10/25/2002 2:48:49 AM, Inge Solvoll [EMAIL PROTECTED] wrote:

The current filter functionality that escapes html is also 
basically 
functionality that could have been done by some tag in JSTL. 
But for 
functionality that is very common, I think it is reasonable to 
focus on 
convenience rather than design principles.

From my perspective, the convenient thing is for this 
transformation tag to live in Jakarta Taglibs, where more 
people can use it. 

The original Struts taglibs were provided as a convenience. But 
now that there are other places where these conveniences are 
better hosted, we should encourage further development take 
place in another forum (Jakarta Taglibs).

At least IMHO =:)

If you agree with this, the interesting discussion here then 
is:
- What is the more common case when outputting text with the 
bean:write 
tag? To view the text with visible linefeeds as inputted by 
the user, or not?
- Are there other filtering tasks that are equally common as 
this? If there 
are, it would be less reasonable to insert linefeed filtering, 
as you said, 
as it would cause a storm of filtering requests...
- Is the need for filtering linefeeds as common as I think? Or 
is my webapp 
an edge case?
- Are there other Struts tag that this discussion applies to?

Which underscores my point. Going past the simple filter option 
opens a Pandora's Box. The best place for a discussion this 
interesting is Jakarta Taglibs, where they specialize in such 
things. 

IMHO, moving forward, the Struts tags should be about exposing 
the Struts framework (as the HTML library does). Generic 
functionality is better handled by other players, like JSTL, 
JSF, and Jakarta Taglibs to fill any gaps in first two. 

But, again, if someone develops a patch, and someone applies 
it, I'll be +0 on enhancements to the original taglibs.

-Ted.



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: cvs commit: jakarta-struts STATUS

[Ted Husted]

If someone wants to maintain this, it should probably be an 
adjunct of the Roadmap. 

Personally, I think we should rely on Bugzilla instead, rather 
than maintain a second document with the same information. 

-Ted.

10/24/2002 11:41:23 PM, [EMAIL PROTECTED] wrote:

jmitchell2002/10/24 20:41:23

  Modified:.STATUS
  Log:
  12 Bugs listed here (Is this being maintained?)
  
  Revision  ChangesPath
  1.61  +2 -2  jakarta-struts/STATUS
  
  Index: STATUS
  
===
  RCS file: /home/cvs/jakarta-struts/STATUS,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- STATUS   20 Oct 2002 18:14:56 -  1.60
  +++ STATUS   25 Oct 2002 03:41:23 -  1.61
  @@ -6,7 +6,7 @@
   OUTSTANDING BUGS IN STRUTS 1.1-b2 AND NIGHTLY 
BUILDS
   ===
=
   
  -20 open bugs to swat!!
  +12 open bugs to swat!!
   
   
   Controller:
  
  
  

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






--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit: jakarta-struts STATUS

[James Mitchell]

I agree, especially after the threads (and a doc update to status.xml) that
describes how we are querying.


James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


 -Original Message-
 From: Ted Husted [mailto:husted;apache.org]
 Sent: Friday, October 25, 2002 7:21 AM
 To: Struts Developers List
 Subject: Re: cvs commit: jakarta-struts STATUS


 If someone wants to maintain this, it should probably be an
 adjunct of the Roadmap.

 Personally, I think we should rely on Bugzilla instead, rather
 than maintain a second document with the same information.

 -Ted.

 10/24/2002 11:41:23 PM, [EMAIL PROTECTED] wrote:

 jmitchell2002/10/24 20:41:23
 
   Modified:.STATUS
   Log:
   12 Bugs listed here (Is this being maintained?)
 
   Revision  ChangesPath
   1.61  +2 -2  jakarta-struts/STATUS
 
   Index: STATUS
   
 ===
   RCS file: /home/cvs/jakarta-struts/STATUS,v
   retrieving revision 1.60
   retrieving revision 1.61
   diff -u -r1.60 -r1.61
   --- STATUS 20 Oct 2002 18:14:56 -  1.60
   +++ STATUS 25 Oct 2002 03:41:23 -  1.61
   @@ -6,7 +6,7 @@
OUTSTANDING BUGS IN STRUTS 1.1-b2 AND NIGHTLY
 BUILDS
===
 =
 
   -20 open bugs to swat!!
   +12 open bugs to swat!!
 
 
Controller:
 
 
 
 
 --
 To unsubscribe, e-mail:   mailto:struts-dev-
 [EMAIL PROTECTED]
 For additional commands, e-mail: mailto:struts-dev-
 [EMAIL PROTECTED]
 
 




 --
 To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc index.xml

[husted]

husted  2002/10/25 05:30:10

  Modified:doc  index.xml
  Log:
  + Update book listings with links to excerpts.
  
  Revision  ChangesPath
  1.31  +11 -1 jakarta-struts/doc/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/index.xml,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- index.xml 12 Oct 2002 17:03:51 -  1.30
  +++ index.xml 25 Oct 2002 12:30:10 -  1.31
   -140,7 +140,7 
   
 p
 The Struts a href=resources/index.htmlbResources/b/a page provides 
links to
  -  everything else published about  Struts, including
  +  everything else published about Struts, including
 a href=resources/books.htmlbooks/a,
 a href=resources/articles.htmlarticles/a,
 a href=resources/tutorials.htmltutorials/a,
   -153,6 +153,16 
 The Struts a href=news.htmlbNews amp; Status/b/a page highlights 
current
 events affecting the framework, including new releases, proposals for new 
features,
 and additions to the Resources page.
  +  /p
  +
  +  /section
  +
  +  section name=Books about Struts href=books
  +
  +  p
  +  Printed books about Struts are available now, and several more are on the way.
  +  A current list of books about Struts is maintained in a 
href=resources/books.htmlthe
  +  resource area/a. Links to excerpts are provided when available.
 /p
   
 /section
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc/resources books.xml

[husted]

husted  2002/10/25 05:30:30

  Modified:doc/resources books.xml
  Log:
  + Update book listings with links to excerpts.
  
  Revision  ChangesPath
  1.9   +45 -15jakarta-struts/doc/resources/books.xml
  
  Index: books.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/books.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- books.xml 12 Oct 2002 16:51:51 -  1.8
  +++ books.xml 25 Oct 2002 12:30:30 -  1.9
   -10,21 +10,51 
   chapter name=Struts Resources href=http://husted.com/struts/resources;
   
   section name=Books
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0672324725/hitchhikeguidetoA/;bStruts 
Kick Start/b/a by James Turner and Kevin Bedell - Not yet published./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=1558608621/hitchhikeguidetoA/;bThe 
Struts Framework: Practical Guide for Programmers/b/a by Sue Spielman - Not yet 
published./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0596003285/hitchhikeguidetoA/;bProgramming
 Jakarta Struts/b/a by Chuck Cavaness - Not yet published. a 
href=http://www.theserverside.com/resources/strutsreview.jsp;Public review draft 
online/a./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeguidetoA/;bStruts 
in Action/b/a by Ted Husted, Cedric Dumoulin, George Franciscus, and David 
Winterfeldt; Foreword by Craig R. McClanahan - Not yet published. (Formerly Java Web 
Development with Struts.) [a href=http://husted.com/struts/book.html;book 
site/a]/p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0471213020/hitchhikeguidetoA/;bMastering
 Jakarta Struts/b/a by James Goodwill - Not yet published./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0971661901/hitchhikeguidetoA/;bStruts 
Fast Track: J2EE / JSP Framework/b/a by Victor Cekvenich - Practical Application 
with Database Access and Struts Extensions. [a 
href=http://sourceforge.net/project/showfiles.php?group_id=55539;book site/a]/p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=1861005512/hitchhikeguidetoA/;bProfessional
 JSP Site Design/b/a - Wrox book by Husted, Kunnumpurath, Lavandowska, Panduranga, 
et al - Features Struts in chapters 2 (The Struts Framework), 6 (Navigation), 8 (Data 
Access Patterns), 12 (Content Management), 13 (Searching), and 14 (Portals)./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0735710953/hitchhikeguidetoA/;bJSP and 
Tag Libraries for Web Development /b/a- by Wellington L. S. Da Silva. Several 
chapters regarding Struts./p
  -pa href=http://www.redbooks.ibm.com/redpieces/pdfs/sg246134.pdf;bWebsphere 
Version 4 Application Development Handbook/b/a font size=1(PDF)/font - 
Chapter 7 covers designing with both the Struts and Websphere frameworks./p
  -pa href=http://shannon.informatik.fh-wiesbaden.de/jsp/index.html;bJava 
Server Pages and J2EE Web-based Applications for Enterprises/b/a - In German, with 
a Chapter regarding MVC and Struts./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0130648841/hitchhikeguidetoA/;bCore 
J2EE Patterns/b/a - Many of these patterns are deployed in Struts./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=1861004958/hitchhikeguidetoA/;bProfessional
 JSP 2nd Edition/b/a - Wrox book - long chapter on Struts./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0130307041/hitchhikeguidetoA/;bAdvanced
 JavaServer Pages/b/a by David Geary - Features template tag library from Struts 
1.0./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0201633612/hitchhikeguidetoA/;bDesign 
Patterns: Elements of Reusable Object-Orientated Software/b/a by Gama, Helm, 
Johnson, and Vlissides - Inspired the core patterns used by Struts./p
  -pa 
href=http://www.amazon.com/exec/obidos/ISBN=0672323095/hitchhikeguidetoA/;bMySQL 
and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL/b/a by 
James Turner - Includes a chapter on Tomcat and Struts./p
  +p
  +a 
href=http://www.amazon.com/exec/obidos/ISBN=0672324725/hitchhikeguidetoA/;bStruts 
Kick Start/b/a by James Turner and Kevin Bedell - Not yet published.
  +/p
  +p
  +a 
href=http://www.amazon.com/exec/obidos/ISBN=1558608621/hitchhikeguidetoA/;bThe 
Struts Framework: Practical Guide for Programmers/b/a by Sue Spielman - Not yet 
published.
  +/p
  +p
  +a 
href=http://www.amazon.com/exec/obidos/ISBN=0596003285/hitchhikeguidetoA/;bProgramming
 Jakarta Struts/b/a by Chuck Cavaness - Not yet published. [a 
href=http://www.oreilly.com/catalog/jakarta/;beta chapter available/a] [a 
href=http://www.theserverside.com/resources/strutsreview.jsp;Public review draft/a]
  +/p
  +p
  +a 
href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeguidetoA/;bStruts 
in Action/b/a (formerly Java Web Development with Struts) by Ted Husted, Cedric 
Dumoulin, George Franciscus, and David Winterfeldt; Foreword by Craig R. McClanahan - 
Not yet published. [a href=http://www.manning.com/husted/;sample 

cvs commit: jakarta-struts/doc/resources extensions.xml

[husted]

husted  2002/10/25 05:31:52

  Modified:doc/resources extensions.xml
  Log:
  + Add back link to David's site (for stubborn 1.0 users).
  
  Revision  ChangesPath
  1.5   +1 -0  jakarta-struts/doc/resources/extensions.xml
  
  Index: extensions.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/extensions.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- extensions.xml14 Aug 2002 15:21:04 -  1.4
  +++ extensions.xml25 Oct 2002 12:31:52 -  1.5
   -33,6 +33,7 
   pa href=http://www.sura.ru/~gonza/bean-factory/;bBean factory/b/a by 
Oleg V Alexeev - Adds the ability to easily link data bean creation to any Struts 
Action. All information about databeans and actions mappings stored in the standard 
Struts configuraton file. /p
   pa href=http://www.livinglogic.de/Struts/;bWorkflow Extension/b/a by 
Matthias Bauer - An extension to the core Struts framework which provides control flow 
between actions./p
   pa href=http://husted.com/struts/resources/struts-menu.zip;bStruts 
Menu/b/a by Scott Sayles (ZIP file for download) - A Struts-compatible web menuing 
component (early release - work in progress) - unzip to a quot;struts-menuquot; 
folder, and see the README./p
  +pa href=http://home.earthlink.net/~dwinterfeldt/;bStruts Validator/b/a 
[Now bundled with Struts 1.1] by David Winterfeldt - Perform basic validations to 
check if a field is required, matches a regular expression, and some basic type 
checking. Different validation rules can be defined for different locales. The 
framework has basic support for user defined constants which can be used in some field 
attributes. The validation routines are modifiable in the validation.xml file so 
custom validation routines can be created and added to the framework./p
   /section
   
   /chapter/body/document
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc/resources consultants.xml

[husted]

husted  2002/10/25 05:32:48

  Modified:doc/resources consultants.xml
  Log:
  + Routine updates.
  
  Revision  ChangesPath
  1.8   +6 -5  jakarta-struts/doc/resources/consultants.xml
  
  Index: consultants.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/consultants.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- consultants.xml   20 Oct 2002 20:10:54 -  1.7
  +++ consultants.xml   25 Oct 2002 12:32:48 -  1.8
  @@ -6,8 +6,8 @@
   authorJames Holmes/author
   titleResources - Consultants - Jakarta Struts/title
   /properties
  -body 
  -chapter name=Struts Resources href=http://husted.com/struts/resources; 
  +body
  +chapter name=Struts Resources href=http://husted.com/struts/resources;
   
   section name=Consultants
   pbProvided as a reference only. No endorsements given or implied.
  @@ -26,7 +26,7 @@
   pa href=http://www.creatrixs.com;Creatrix/a - a 
href=mailto:sami.elhini;creatrixs.com[EMAIL PROTECTED]/a./p
   pa href=http://www.caraveltech.com/struts/;Caravel Technologies/a - a 
href=mailto:wchao;caraveltech.comWellie Chao/a./p
   pa href=http://www.chikli.com/training_support.html;Chikli Consulting LLC/a 
- a href=mailto:nayan;chikli.comNayan Hajratwala/a./p
  -pa href=http://www.christopherbenson.com;Christopher Benson/a - a 
href=mailto:benson;mindspring.com Christopher Benson/a./p  
  +pa href=http://www.christopherbenson.com;Christopher Benson/a - a 
href=mailto:benson;mindspring.com Christopher Benson/a./p
   pa href=http://www.differentum.com;Differentum/a - a 
href=mailto:info;differentum.comSanjay Sharma/a./p
   pa href=http://www.eblox.com/;eBlox/a - a 
href=mailto:andrewb;eblox.com[EMAIL PROTECTED]/a./p
   pa href=http://www.etmint.com;ETM International/a - a 
href=mailto:mathias.bogaert;etmint.com[EMAIL PROTECTED]/a/p
  @@ -49,15 +49,16 @@
   pa href=http://www.objectwave.com;ObjectWave Corp./a - a 
href=mailto:info;objectwave.com[EMAIL PROTECTED]/a/p
   pa href=http://www.orbeon.com/;Orbeon/a - a 
href=mailto:gbouzeid;orbeon.comGilbert Bouzeid/a./p
   pa href=http://www.oio.de/struts-consulting.htm;Orientation in Objects 
(Germany)/a - a href=mailto:bayer;oio.deThomas Bayer/a./p
  -pa href=http://www.projectrefinery.com;Project Refinery/a - a 
href=mailto:jsmith;projectrefinery.com Jason Smith/a/p  
  +pa href=http://www.projectrefinery.com;Project Refinery/a - a 
href=mailto:jsmith;projectrefinery.com Jason Smith/a/p
   pa href=http://www.raibledesigns.com/;Raible Designs/a - a 
href=mailto:matt_raible;yahoo.comMatt Raible/a./p
  +pa href=http://www.runtime-collective.com;Runtime Collective/a - a 
href=mailto:steve;runtime-collective.comSteve Crossan/a/p
   pa href=http://www.sbti.com/;Segue Solutions/a  - a 
href=mailto:jthomas;segue.bizJohn J. Thomas/a./p
   pa href=http://www.scioworks.com/;Scioworks Technologies [Singapore]/a  - a 
href=mailto:info;scioworks.com[EMAIL PROTECTED]/a./p
   pa href=http://www.sharedskills.com/;Shared Skills Ltd (UK)/a - a 
href=mailto:mike.way;sharedskills.comMike Way/a./p
   pa href=http://softwareMentor.com/;SoftwareMentor/a - a 
href=mailto:tim;softwareMentor.comTim Biernat/a./p
   pa href=http://www.solutionarray.com/;Solution Array/a - a 
href=mailto:chkmiec;hotmail.comChris Kmiec/a./p
   pa href=http://www.connection.se/;Swedish Connection/a - a 
href=mailto:micke;connection.seMikael Eriksson/a./p
  -pa href=http://www.sysdeo.com;Sysdeo [FR]/a - a 
href=mailto:abuisine;sysdeo.com Arnaud Buisine/a./p  
  +pa href=http://www.sysdeo.com;Sysdeo [FR]/a - a 
href=mailto:abuisine;sysdeo.com Arnaud Buisine/a./p
   pa href=http://www.tallan.com/;Tallan/a - a 
href=mailto:michael.grassotti;tallan.comMichael Grassotti/a./p
   pa href=http://www.thales-is.ch/;Thalles Information Services/a - a 
href=mailto:markus.colombo;thales-is.chMarkus Collumbo/a./p
   pa href=http://www.tngtech.de/;TNGtech/a - a 
href=mailto:henrik.klagges;tngtech.comHenrik Klagges/a./p
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc/userGuide dev_validator.xml dev_tiles.xml

[husted]

husted  2002/10/25 05:37:53

  Modified:doc/userGuide dev_validator.xml dev_tiles.xml
  Log:
  + Add  book excerpts to Resource sections.
  
  Revision  ChangesPath
  1.9   +57 -28jakarta-struts/doc/userGuide/dev_validator.xml
  
  Index: dev_validator.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- dev_validator.xml 24 Oct 2002 18:42:20 -  1.8
  +++ dev_validator.xml 25 Oct 2002 12:37:53 -  1.9
   -11,39 +11,66 
   
   section href=validator name=Struts Validator
   
  +p
   [:TODO:]
  -pCover basic functionality as documented on David's web site.
  +/p
  +
  +p
  +Cover basic functionality as documented on David's web site.
   a href=http://home.earthlink.net/~dwinterfeldt/;Validation Framework for Struts 
/a 
   /p
   
  -p Struts 1.1 has added additional functionality over the original validator
  -contributed by David Winterfeldt/p
  +p
  +Struts 1.1 has added additional functionality over the original validator
  +contributed by David Winterfeldt.
  +/p
  +
   ul
  -li Conditionally required fields/li
  -li intRange() amp; floatRange() methods in both JavaScript and Java/li
  +li
  +  Conditionally required fields
  +/li
  +li
  +  intRange() amp; floatRange() methods in both JavaScript and Java
  +/li
   /ul
  -p There have also been changes in the validator behavior and deprecation of 
functionality
  +p
  +There have also been changes in the validator behavior and deprecation of 
functionality
   /p
   ul
  -li The validator xml files now validate against the DTD stored in the 
commons-validator.jar. /li
  -li The default valiator-rules.xml now ignores blank fields for all the basic 
validation types.
  -If you require a field to be present then to your applications validator.xml 
  -field definition add required to the depends attribute./li
  -li The Javascript Tag has new attributes defined. /li
  -li Deprecation of range() methods in both JavaScript and Java/li
  -li Deprecation of StrutsVlaidator amp; StrutsValidatorUtil/li
  +li
  +  The validator xml files now validate against the DTD stored in the 
commons-validator.jar. 
  +/li
  +li
  +  The default valiator-rules.xml now ignores blank fields for all the basic 
validation types.
  +  If you require a field to be present then to your applications validator.xml 
  +  field definition add required to the depends attribute.
  +/li
  +li
  +  The Javascript Tag has new attributes defined.
  +/li
  +li
  +  Deprecation of range() methods in both JavaScript and Java
  +/li
  +li
  +  Deprecation of StrutsVlaidator amp; StrutsValidatorUtil
  +/li
   /ul
   
   p
   The most fundamental change is the ability to conditionally
   require validator fields based on the value of other fields.
   It allows you to define logic like only validate this field if field X is non-
  -null and field Y equals male./p
  +null and field Y equals male.
  +/p
  +
   p
   The syntax looks like this:
   /p
  +
   p
  -If you have this in your struts-config.xml /p
  +If you have this in your struts-config.xml
  +/p
  +
   ol
   pre![CDATA[
   form-bean name=dependentlistForm
   -57,11 +84,15 
   /form-bean
   ]]/pre
   /ol
  +
   p
   Where dependent is a bean that has properties lastName, firstName, dob, 
  -coverageType /p
  +coverageType
  +/p
  +
   p
  -You can define a validation:/p
  +You can define a validation:
  +/p
   
   pre![CDATA[
 form name=dependentlistForm
   -140,18 +171,16 
   indexed field as firstName.  Same thing for dob, except that we validate for 
   date if not blank.
   /p
  +
   p
   The coverageType is only required if the lastName for the same indexed bean is 
   not null, and also if the non-indexed field insureDependents is true.
   /p
  +
   p
   You can have an arbitrary number of fields by using the [n] syntax, the only 
   restriction is that they must all be AND or OR, you can't mix.
   /p
  -
  -
  -
  -
   /section
   
   section href=tiles name=Validator API Guide
   -163,14 +192,14 
   
   /section
   
  -!-- 
  -  authorTed Husted/author 
   section href=resources name=Validator Resources
  -pbuValidating Input/u/b by David Winterfeldt and Ted Husted. 
  -Sample chapter from uJava Web Development with Struts/u; available as a 
  -ufree download/u (PDF).
  +p
  +a 
href=http://www.manning.com/getpage.html?project=hustedamp;filename=chapters.html;
  +bValidating user input/b/a by Daid Winterfeldt and Ted Husted.
  +Sample chapter from 
  +a 
href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeguidetoA/;Struts in 
Action/a; 
  +available as a free download (PDF).
   /p
  -/section
  ---
   
  +/section
   /chapter/body/document
  
  
  
  1.10  +256 -256  jakarta-struts/doc/userGuide/dev_tiles.xml
  
  Index: dev_tiles.xml
  ===
  RCS 

cvs commit: jakarta-struts/doc index.xml

[husted]

husted  2002/10/25 05:45:33

  Modified:doc  index.xml
  Log:
  + Add  [FRIDAY] blurb.
  
  Revision  ChangesPath
  1.32  +10 -2 jakarta-struts/doc/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/index.xml,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- index.xml 25 Oct 2002 12:30:10 -  1.31
  +++ index.xml 25 Oct 2002 12:45:33 -  1.32
   -130,13 +130,21 
 p
 If you really can't find the answer to your question in the a 
href=#faqsFAQs/a or
 a href=http://nagoya.apache.org/eyebrowse/SummarizeList?listId=42;list 
archive/a,
  -  you can post your query to the Struts User list -- BUT YOU MUST SUBSCRIBE TO THE
  +  you can post your query to the Struts User list -- bBUT YOU MUST SUBSCRIBE TO 
THE
 a href=mailto:struts-user-subscribe;jakarta.apache.orgUSER LIST/a
 OR THE
 a href=mailto:struts-user-digest-subscribe;jakarta.apache.orgUSER LIST 
DIGEST/a
  -  BEFORE POSTING. If you would rather not subscribe to a list, you can go through 
the
  +  BEFORE POSTING/b. If you would rather not subscribe to a list, you can go 
through the
 a href=http://www.proj.com/subscribe.jsp;BaseBeans Struts Newsgroup/a 
instead.
 /p
  +
  +  blockquote
  +  Please note that the Struts User list enjoys a casual friday policy. More 
off-topic
  +  messages are tolerated on Fridays so long as the message is prefixed with the 
token
  +  [FRIDAY]. If you'd rather not be troubled by these postings, please set your
  +  mail filter accordingly. Posting [FRIDAY] articles on any other weekday is 
bstrongly
  +  discouraged/b. We thank you for your cooperation.
  +  /blockquote
   
 p
 The Struts a href=resources/index.htmlbResources/b/a page provides 
links to
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc status.xml

[husted]

husted  2002/10/25 05:50:32

  Modified:doc  status.xml
  Log:
  + Add note to Roadmap where we can document updating the Website from CVS.
  
  Revision  ChangesPath
  1.5   +5 -1  jakarta-struts/doc/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/status.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- status.xml20 Oct 2002 17:06:08 -  1.4
  +++ status.xml25 Oct 2002 12:50:32 -  1.5
   -106,4 +106,8 
   /ul
   /section
   
  +section
  +pfont size=-2Website updated from CVS: 2002 OCT 25 by husted./font/p
  +/section
  +
   /chapter/body/document
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

nested:iterate with a HashMap

[Jerred Wilson]

I'm trying to use the nested:iterate tag to iterate through a HashMap.  The 
logic:iterate documentation shows that I should be able to use the following to do 
so, but I always get the error:

java.lang.IllegalArgumentException: Property 'variablesThatProducedErrors' is not 
indexed

where 'variablesThatProducedErrors is a Map'.

Why doesn't this work?  Does anyone have this working?

-Original Message-
From: [EMAIL PROTECTED] [mailto:husted;apache.org]
Sent: Friday, October 25, 2002 7:51 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/doc status.xml


husted  2002/10/25 05:50:32

  Modified:doc  status.xml
  Log:
  + Add note to Roadmap where we can document updating the Website from CVS.
  
  Revision  ChangesPath
  1.5   +5 -1  jakarta-struts/doc/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/status.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- status.xml20 Oct 2002 17:06:08 -  1.4
  +++ status.xml25 Oct 2002 12:50:32 -  1.5
  @@ -106,4 +106,8 @@
   /ul
   /section
   
  +section
  +pfont size=-2Website updated from CVS: 2002 OCT 25 by husted./font/p
  +/section
  +
   /chapter/body/document
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: nested:iterate with a HashMap

[Jerred Wilson]

Sorry, here's the jsp tags:

 nested:iterate id=element property = variablesThatProducedErrors
td
bean:write name=element property =name/
nested:write name=element property = value/
/td
 /nested:iterate

-Original Message-
From: Jerred Wilson 
Sent: Friday, October 25, 2002 8:06 AM
To: 'Struts Developers List'
Subject: nested:iterate with a HashMap


I'm trying to use the nested:iterate tag to iterate through a HashMap.  The 
logic:iterate documentation shows that I should be able to use the following to do 
so, but I always get the error:

java.lang.IllegalArgumentException: Property 'variablesThatProducedErrors' is not 
indexed

where 'variablesThatProducedErrors is a Map'.

Why doesn't this work?  Does anyone have this working?

-Original Message-
From: [EMAIL PROTECTED] [mailto:husted;apache.org]
Sent: Friday, October 25, 2002 7:51 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/doc status.xml


husted  2002/10/25 05:50:32

  Modified:doc  status.xml
  Log:
  + Add note to Roadmap where we can document updating the Website from CVS.
  
  Revision  ChangesPath
  1.5   +5 -1  jakarta-struts/doc/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/status.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- status.xml20 Oct 2002 17:06:08 -  1.4
  +++ status.xml25 Oct 2002 12:50:32 -  1.5
  @@ -106,4 +106,8 @@
   /ul
   /section
   
  +section
  +pfont size=-2Website updated from CVS: 2002 OCT 25 by husted./font/p
  +/section
  +
   /chapter/body/document
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: nested:iterate with a HashMap

[Arron Bates]

For one, this is a struts-user mailing list type question.

But give this a bash...

nested:iterate property=variablesThatProducedErrors
 nested:write property=name/
 nested:write property=value/
/nested:iterate

...the nested tags don't need the name properties in the child tags. 
It's all sorted out by the parent tags.

If the above doesn't work, please post the response to the struts-user 
list. Many more people to help you solve your problem sooner.

Arron.


Jerred Wilson wrote:

Sorry, here's the jsp tags:

nested:iterate id=element property = variablesThatProducedErrors
   td
   bean:write name=element property =name/
   nested:write name=element property = value/
   /td
/nested:iterate

-Original Message-
From: Jerred Wilson 
Sent: Friday, October 25, 2002 8:06 AM
To: 'Struts Developers List'
Subject: nested:iterate with a HashMap


I'm trying to use the nested:iterate tag to iterate through a HashMap.  The logic:iterate documentation shows that I should be able to use the following to do so, but I always get the error:

java.lang.IllegalArgumentException: Property 'variablesThatProducedErrors' is not indexed

where 'variablesThatProducedErrors is a Map'.

Why doesn't this work?  Does anyone have this working?

-Original Message-
From: [EMAIL PROTECTED] [mailto:husted;apache.org]
Sent: Friday, October 25, 2002 7:51 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/doc status.xml


husted  2002/10/25 05:50:32

 Modified:doc  status.xml
 Log:
 + Add note to Roadmap where we can document updating the Website from CVS.
 
 Revision  ChangesPath
 1.5   +5 -1  jakarta-struts/doc/status.xml
 
 Index: status.xml
 ===
 RCS file: /home/cvs/jakarta-struts/doc/status.xml,v
 retrieving revision 1.4
 retrieving revision 1.5
 diff -u -r1.4 -r1.5
 --- status.xml	20 Oct 2002 17:06:08 -	1.4
 +++ status.xml	25 Oct 2002 12:50:32 -	1.5
 @@ -106,4 +106,8 @@
  /ul
  /section
  
 +section
 +pfont size=-2Website updated from CVS: 2002 OCT 25 by husted./font/p
 +/section
 +
  /chapter/body/document
 
 
 

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

 





--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Validator Integration

[David Graham]

It struck me the other day that the validator could be further integrated 
into struts.  I'm not sure about my ideas so I want to get your thoughts.  
Why should people need to subclass ValidatorActionForm instead of ActionForm 
to use the validator?  What forms have you built that didn't need 
validation?

My idea is that the ValidatorActionForm and ValidatorForm (why are there 2?) 
behavior should be included in ActionForm and have those classes removed.  I 
think this will maintain backward compatibility because if the developer 
hasn't defined any validation rules for a form then we could return null 
from validate().

Further, we could include validator configuration tags in struts-config.xml 
instead of using a plugin.  This would signify that validator is an integral 
piece of struts that most people want to use (which I believe they do).

This is probably a post 1.1 idea but I thought I'd throw it out here.
What do you think?

David





_
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13973] New: - Tomcat shutdown Loop

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13973.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13973

Tomcat shutdown Loop

   Summary: Tomcat shutdown Loop
   Product: Struts
   Version: 1.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I've a problem when I try to shutdown the Tomcat Server (4.1.12) the a Struts 
1.0.2 application.
I've uses a Datasource config in the Struts-Config.xml

During the shutdown, the Close() method in the GenericDataSource class have an 
infinte LOOP and I must force the kill of the server.
This method is called to close all the connection the datasource initialized. 

Have anybody got the same problem?

Thanks!

Pierfranco Lai

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[James Holmes]

See Ted's response to my very same question a couple
of days ago.

-james

--- David Graham [EMAIL PROTECTED] wrote:
 My idea is that the ValidatorActionForm and
 ValidatorForm (why are there 2?) 


__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[Eddie Bush]

I just forwarded the discussion to you, David.  It happened on the 23rd.

David Graham wrote:


It struck me the other day that the validator could be further 
integrated into struts.  I'm not sure about my ideas so I want to get 
your thoughts.  Why should people need to subclass ValidatorActionForm 
instead of ActionForm to use the validator?  What forms have you built 
that didn't need validation?

My idea is that the ValidatorActionForm and ValidatorForm (why are 
there 2?) behavior should be included in ActionForm and have those 
classes removed.  I think this will maintain backward compatibility 
because if the developer hasn't defined any validation rules for a 
form then we could return null from validate().

Further, we could include validator configuration tags in 
struts-config.xml instead of using a plugin.  This would signify that 
validator is an integral piece of struts that most people want to use 
(which I believe they do).

This is probably a post 1.1 idea but I thought I'd throw it out here.
What do you think?

David





_
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:struts-dev-help;jakarta.apache.org




--
Eddie Bush




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: [struts-el] HTML taglib

[Eddie Bush]

It doesn't appear to make any difference inside NB.  I even restarted NB 
to ensure if there was some funky caching going on I was unaware of it 
would (hopefully) be updated.  No dice.

I think testing it directly under Tomcat shows this is an issue with NB 
though.  I'm fairly certain this probably has to do with the JSP 
compiler.  More precisely, I believe it probably has to do with the JSP 
compiler available under Tomcat 4.0.  I'm not 100% certain on this 
though.  Is this conceivable?

I have a couple different installs of Tomcat.  One is used by NB 
internally (TC 4.0.4) and another which I installed from binary (4.1.12, 
I think).  Under NB there are issues.  However, I've seen that the TC 
4.1.12 install will compile the page just fine.  If that doesn't just 
blow a person's mind.  Perhaps it has something to do with my running 
JDK 1.4_01.  In any case, I think we can rest assured it's not a bug in 
struts-el.  I'll just deal with it.  Thanks for your assistance though, 
David.  If you have any other suggestions, I'm happy to try them.

David M. Karr wrote:

Eddie == Eddie Bush [EMAIL PROTECTED] writes:



   Eddie Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB.  I finally
   Eddie got a chance to try it under Tomcat (4.1.12) and it worked *just fine*.  Sorry
   Eddie - next time test outside of the IDE before I assume something is up.  What a
   Eddie PITA.

There's something silly I'd like you to try, just as an experiment, if you can
still get it to fail in NB.

In ELHtmlTag.java, add just the following line:

private static Class beanInfoClass = ELHtmlTagBeanInfo.class;

and retest.


--
Eddie Bush




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: HTML formatting of newline characters with bean:write tag

[Inge Solvoll]

I can see that there are some very good points for not including html 
encoding of newline characters in the bean:write tag. I also think there 
are one or two good points for the opposite. Anyway, I've modified my 
solution a bit, so now it can be applied as a patch to the bean:write and 
nested:write tags.

There are 3 modified files:
- WriteTag.java
- struts-bean.tld
- struts-nested.tld

I've added an attribute, encodeLineFeed, that defaults to false. If true, 
all linebreaks are HTML encoded after any filtering of other HTML.

If anyone wants to use these, just send me a mail!

Inge :)



At 07:16 25.10.2002 -0400, you wrote:
10/25/2002 2:48:49 AM, Inge Solvoll [EMAIL PROTECTED] wrote:

The current filter functionality that escapes html is also
basically
functionality that could have been done by some tag in JSTL.
But for
functionality that is very common, I think it is reasonable to
focus on
convenience rather than design principles.

From my perspective, the convenient thing is for this
transformation tag to live in Jakarta Taglibs, where more
people can use it.

The original Struts taglibs were provided as a convenience. But
now that there are other places where these conveniences are
better hosted, we should encourage further development take
place in another forum (Jakarta Taglibs).

At least IMHO =:)

If you agree with this, the interesting discussion here then
is:
- What is the more common case when outputting text with the
bean:write
tag? To view the text with visible linefeeds as inputted by
the user, or not?
- Are there other filtering tasks that are equally common as
this? If there
are, it would be less reasonable to insert linefeed filtering,
as you said,
as it would cause a storm of filtering requests...
- Is the need for filtering linefeeds as common as I think? Or
is my webapp
an edge case?
- Are there other Struts tag that this discussion applies to?

Which underscores my point. Going past the simple filter option
opens a Pandora's Box. The best place for a discussion this
interesting is Jakarta Taglibs, where they specialize in such
things.

IMHO, moving forward, the Struts tags should be about exposing
the Struts framework (as the HTML library does). Generic
functionality is better handled by other players, like JSTL,
JSF, and Jakarta Taglibs to fill any gaps in first two.

But, again, if someone develops a patch, and someone applies
it, I'll be +0 on enhancements to the original taglibs.



-Ted.



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: HTML formatting of newline characters with bean:write tag

[Craig R. McClanahan]

On Fri, 25 Oct 2002, Inge Solvoll wrote:


 I agree with you on most of this. I can clearly see that it is hard to draw
 the line when to stop filtering in the bean:write tag and other tags and
 leave this to other taglibs.

 The current filter functionality that escapes html is also basically
 functionality that could have been done by some tag in JSTL. But for
 functionality that is very common, I think it is reasonable to focus on
 convenience rather than design principles.


And this is where I think your assumptions might be challenged.

Struts has been around for over two years, released for over 18 months,
downloaded many many thousands of times, employed in apps all over the
world, and your request is the first I can recall asking for this
particular feature.  That doesn't imply to me that the need for embedding
br in the bean:write tag's output is a very common requirement.

 If you agree with this, the interesting discussion here then is:
 - What is the more common case when outputting text with the bean:write
 tag? To view the text with visible linefeeds as inputted by the user, or not?

The obvious answer is not, because that's the way it has always worked.

The existing filter attribute is there because it avoids security
vulnerabilities (such as cross-site scripting problems from displaying
data entered by a user that might contain HTML elements in it) -- it's not
there for layout management.

 - Are there other filtering tasks that are equally common as this? If there
 are, it would be less reasonable to insert linefeed filtering, as you said,
 as it would cause a storm of filtering requests...

Even if we were to add this particular type of filtering, you ultimately
end up with a limited set of hard coded options.  Nesting tags, on the
other hand, is extensible to any kind of filtering, and doesn't require
modifying ANY of the Struts tags (or any other tags) to make it usable.

 - Is the need for filtering linefeeds as common as I think? Or is my webapp
 an edge case?

As I commented above, this is the first time I can recall ever discussing
it with respect to Struts tags.

 - Are there other Struts tag that this discussion applies to?


With nesting, it wouldn't matter :-).

And it wouldn't matter for non-Struts tags either :-).

Craig


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[Ted Husted]

10/25/2002 10:34:52 AM, David Graham [EMAIL PROTECTED] 
wrote:

It struck me the other day that the validator could be further 
integrated 
into struts.  I'm not sure about my ideas so I want to get 
your thoughts.  
Why should people need to subclass ValidatorActionForm instead 
of ActionForm 
to use the validator?  What forms have you built that didn't 
need 
validation?

My idea is that the ValidatorActionForm and ValidatorForm (why 
are there 2?) 
behavior should be included in ActionForm and have those 
classes removed.  I 
think this will maintain backward compatibility because if the 
developer 
hasn't defined any validation rules for a form then we could 
return null 
from validate().

Further, we could include validator configuration tags in 
struts-config.xml 
instead of using a plugin.  This would signify that validator 
is an integral 
piece of struts that most people want to use (which I believe 
they do).

This is probably a post 1.1 idea but I thought I'd throw it 
out here.
What do you think?

David





__
___
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


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






--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13973] - Tomcat shutdown Loop

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13973.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13973

Tomcat shutdown Loop





--- Additional Comments From [EMAIL PROTECTED]  2002-10-25 17:02 ---
Could you post some additional details such as code snippets of how and where 
you are using the datasource.

Thanks
James Mitchell

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[Ted Husted]

I've been using the Validator for going on three years now, but 
I don't think I would ever want to describe it as an integal 
part of Struts. Struts provides a validation hotspot, and we 
provide the Validation as something people can plug into that 
spot. But we want to be very clear that it is only one of many 
possible solutions to validation. 

We provide direct support for the Validator as a convenience, 
but IMHO, it is not part of the true Struts core. (Of course, I 
don't consider the tags part of the true Struts core either =:)

I'd also be very cold on amending the struts-config with the 
specifics for any optional component, the Validator included. 
Ideally, the Validation config could be shared with other 
platforms (not just Struts), and should be a standalone file. 

As mentioned elsewhere, there were two classes since some 
people (or maybe one person) wanted to key on the action path 
rather than the action attribute. But if we were patch this to 
use a switch, mores the better.

-Ted.

10/25/2002 10:34:52 AM, David Graham [EMAIL PROTECTED] 
wrote:

It struck me the other day that the validator could be further 
integrated 
into struts.  I'm not sure about my ideas so I want to get 
your thoughts.  y
Why should people need to subclass ValidatorActionForm instead 
of ActionForm 
to use the validator?  What forms have you built that didn't 
need 
validation?

My idea is that the ValidatorActionForm and ValidatorForm (why 
are there 2?) 
behavior should be included in ActionForm and have those 
classes removed.  I 
think this will maintain backward compatibility because if the 
developer 
hasn't defined any validation rules for a form then we could 
return null 
from validate().

Further, we could include validator configuration tags in 
struts-config.xml 
instead of using a plugin.  This would signify that validator 
is an integral 
piece of struts that most people want to use (which I believe 
they do).

This is probably a post 1.1 idea but I thought I'd throw it 
out here.
What do you think?

David





__
___
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


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






--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[Joe Germuska]

David:

we saw recently that you and I disagree on the core nature of the 
validator package.  But even if 90% of Struts users decide to 
validate with Validator, I don't think that's a compelling argument 
to change the behavior of ActionForm.

First, doing so would break backwards compatibility.  Second, by 
tying relatively complex validation into the core class, you sort of 
cut off other possible ways to extend ActionForm.  Yes, you could 
argue that subclasses can override the validate() method and 
subsequently ignore anything in the ActionForm class which refers to 
validator, but that's not really very clean design.  Keep the core 
classes simple and focused on the minimal requirements for 
interacting with other objects, and add subclasses whenever more 
specialized behavior is needed.

Is it a great burden to extend a different class if you want to use 
the validator framework to validate form input?  I do agree that 
having two separate subclasses which vary only in how they key to 
validation rules is unnecessarily complex, but otherwise, what 
benefits do such a change bring?

Joe



At 11:42 AM -0600 2002/10/25, David Graham wrote:
Thanks for the input Ted.  I was only suggesting changing 
struts-config if validator was truely merged; I agree that optional 
components don't belong there.  The validation rules file should be 
separate but I'm suggesting that the validator not be a plugin and 
have an entry similar to message-resources or form-beans.

Now the question is whether the validator is a core component?
I don't know what you all define as core but I believe this is a 
core aspect.  How many forms have you built that didn't need 
validation of at least one required field (if no form fields are 
required I question the value of the form)?

What are the various options for validation?  I see 2 built into 
Struts: coding a form bean's validate() method and using the 
validator.  What I'm suggesting is that the ActionForm.validate() 
method use the validator by default.

I just don't see any need to subclass a different ActionForm class 
to use the validator when it seems that this will become the 
predominant form of validation.

David





From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 13:09:10 -0400

I've been using the Validator for going on three years now, but
I don't think I would ever want to describe it as an integal
part of Struts. Struts provides a validation hotspot, and we
provide the Validation as something people can plug into that
spot. But we want to be very clear that it is only one of many
possible solutions to validation.

We provide direct support for the Validator as a convenience,
but IMHO, it is not part of the true Struts core. (Of course, I
don't consider the tags part of the true Struts core either =:)

I'd also be very cold on amending the struts-config with the
specifics for any optional component, the Validator included.
Ideally, the Validation config could be shared with other
platforms (not just Struts), and should be a standalone file.

As mentioned elsewhere, there were two classes since some
people (or maybe one person) wanted to key on the action path
rather than the action attribute. But if we were patch this to
use a switch, mores the better.

-Ted.

10/25/2002 10:34:52 AM, David Graham [EMAIL PROTECTED]
wrote:


It struck me the other day that the validator could be further

integrated

into struts.  I'm not sure about my ideas so I want to get

your thoughts.  y

Why should people need to subclass ValidatorActionForm instead

of ActionForm

to use the validator?  What forms have you built that didn't

need

validation?

My idea is that the ValidatorActionForm and ValidatorForm (why

are there 2?)

behavior should be included in ActionForm and have those

classes removed.  I
 think this will maintain backward compatibility because if the
developer

hasn't defined any validation rules for a form then we could

return null

from validate().

Further, we could include validator configuration tags in

struts-config.xml

instead of using a plugin.  This would signify that validator

is an integral

piece of struts that most people want to use (which I believe

they do).


This is probably a post 1.1 idea but I thought I'd throw it

out here.

What do you think?

David





__

___

Unlimited Internet access -- and 2 months free!  Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   mailto:struts-dev-

[EMAIL PROTECTED]

For additional commands, e-mail: mailto:struts-dev-

[EMAIL PROTECTED]








--
To unsubscribe, e-mail:  
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[David Graham]

I'm mainly suggesting this to get some new ideas out there.  I don't see how 
it would break backwards compatibility.  As I stated earlier, if a developer 
doesn't use the validator or define a validation rule for a form then the 
validate() method could just return null as usual.  You wouldn't have to 
override validate to maintain compatibility.  Is there something else I'm 
missing?

It's not necessarily a burden to extend a different class but I do think 
it's beneficial for the framework to inherently support a high class 
validation framework without the developer being exposed to extending 
special classes.

David






From: Joe Germuska [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 13:16:10 -0500

David:

we saw recently that you and I disagree on the core nature of the 
validator package.  But even if 90% of Struts users decide to validate with 
Validator, I don't think that's a compelling argument to change the 
behavior of ActionForm.

First, doing so would break backwards compatibility.  Second, by tying 
relatively complex validation into the core class, you sort of cut off 
other possible ways to extend ActionForm.  Yes, you could argue that 
subclasses can override the validate() method and subsequently ignore 
anything in the ActionForm class which refers to validator, but that's not 
really very clean design.  Keep the core classes simple and focused on the 
minimal requirements for interacting with other objects, and add subclasses 
whenever more specialized behavior is needed.

Is it a great burden to extend a different class if you want to use the 
validator framework to validate form input?  I do agree that having two 
separate subclasses which vary only in how they key to validation rules is 
unnecessarily complex, but otherwise, what benefits do such a change bring?

Joe



At 11:42 AM -0600 2002/10/25, David Graham wrote:
Thanks for the input Ted.  I was only suggesting changing struts-config if 
validator was truely merged; I agree that optional components don't belong 
there.  The validation rules file should be separate but I'm suggesting 
that the validator not be a plugin and have an entry similar to 
message-resources or form-beans.

Now the question is whether the validator is a core component?
I don't know what you all define as core but I believe this is a core 
aspect.  How many forms have you built that didn't need validation of at 
least one required field (if no form fields are required I question the 
value of the form)?

What are the various options for validation?  I see 2 built into Struts: 
coding a form bean's validate() method and using the validator.  What I'm 
suggesting is that the ActionForm.validate() method use the validator by 
default.

I just don't see any need to subclass a different ActionForm class to use 
the validator when it seems that this will become the predominant form of 
validation.

David





From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 13:09:10 -0400

I've been using the Validator for going on three years now, but
I don't think I would ever want to describe it as an integal
part of Struts. Struts provides a validation hotspot, and we
provide the Validation as something people can plug into that
spot. But we want to be very clear that it is only one of many
possible solutions to validation.

We provide direct support for the Validator as a convenience,
but IMHO, it is not part of the true Struts core. (Of course, I
don't consider the tags part of the true Struts core either =:)

I'd also be very cold on amending the struts-config with the
specifics for any optional component, the Validator included.
Ideally, the Validation config could be shared with other
platforms (not just Struts), and should be a standalone file.

As mentioned elsewhere, there were two classes since some
people (or maybe one person) wanted to key on the action path
rather than the action attribute. But if we were patch this to
use a switch, mores the better.

-Ted.

10/25/2002 10:34:52 AM, David Graham [EMAIL PROTECTED]
wrote:


It struck me the other day that the validator could be further

integrated

into struts.  I'm not sure about my ideas so I want to get

your thoughts.  y

Why should people need to subclass ValidatorActionForm instead

of ActionForm

to use the validator?  What forms have you built that didn't

need

validation?

My idea is that the ValidatorActionForm and ValidatorForm (why

are there 2?)

behavior should be included in ActionForm and have those

classes removed.  I
 think this will maintain backward compatibility because if the
developer

hasn't defined any validation rules for a form then we could

return null

from validate().

Further, we could include validator 

RE: Validator Integration

[James Mitchell]

I have no idea on the level of effort required, but it would be nice to be
able to drop in my own Validator implementation like I can logging, jdbc or
message resources.

Your thought?



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)




 -Original Message-
 From: David Graham [mailto:dgraham1980;hotmail.com]
 Sent: Friday, October 25, 2002 2:48 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Validator Integration


 I'm mainly suggesting this to get some new ideas out there.  I
 don't see how
 it would break backwards compatibility.  As I stated earlier, if
 a developer
 doesn't use the validator or define a validation rule for a form then the
 validate() method could just return null as usual.  You wouldn't have to
 override validate to maintain compatibility.  Is there something else I'm
 missing?

 It's not necessarily a burden to extend a different class but I do think
 it's beneficial for the framework to inherently support a high class
 validation framework without the developer being exposed to extending
 special classes.

 David






 From: Joe Germuska [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED]
 Subject: Re: Validator Integration
 Date: Fri, 25 Oct 2002 13:16:10 -0500
 
 David:
 
 we saw recently that you and I disagree on the core nature of the
 validator package.  But even if 90% of Struts users decide to
 validate with
 Validator, I don't think that's a compelling argument to change the
 behavior of ActionForm.
 
 First, doing so would break backwards compatibility.  Second, by tying
 relatively complex validation into the core class, you sort of cut off
 other possible ways to extend ActionForm.  Yes, you could argue that
 subclasses can override the validate() method and subsequently ignore
 anything in the ActionForm class which refers to validator, but
 that's not
 really very clean design.  Keep the core classes simple and
 focused on the
 minimal requirements for interacting with other objects, and add
 subclasses
 whenever more specialized behavior is needed.
 
 Is it a great burden to extend a different class if you want to use the
 validator framework to validate form input?  I do agree that having two
 separate subclasses which vary only in how they key to
 validation rules is
 unnecessarily complex, but otherwise, what benefits do such a
 change bring?
 
 Joe
 
 
 
 At 11:42 AM -0600 2002/10/25, David Graham wrote:
 Thanks for the input Ted.  I was only suggesting changing
 struts-config if
 validator was truely merged; I agree that optional components
 don't belong
 there.  The validation rules file should be separate but I'm suggesting
 that the validator not be a plugin and have an entry similar to
 message-resources or form-beans.
 
 Now the question is whether the validator is a core component?
 I don't know what you all define as core but I believe this is a core
 aspect.  How many forms have you built that didn't need
 validation of at
 least one required field (if no form fields are required I question the
 value of the form)?
 
 What are the various options for validation?  I see 2 built
 into Struts:
 coding a form bean's validate() method and using the validator.
  What I'm
 suggesting is that the ActionForm.validate() method use the
 validator by
 default.
 
 I just don't see any need to subclass a different ActionForm
 class to use
 the validator when it seems that this will become the
 predominant form of
 validation.
 
 David
 
 
 
 
 
 From: Ted Husted [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED]
 Subject: Re: Validator Integration
 Date: Fri, 25 Oct 2002 13:09:10 -0400
 
 I've been using the Validator for going on three years now, but
 I don't think I would ever want to describe it as an integal
 part of Struts. Struts provides a validation hotspot, and we
 provide the Validation as something people can plug into that
 spot. But we want to be very clear that it is only one of many
 possible solutions to validation.
 
 We provide direct support for the Validator as a convenience,
 but IMHO, it is not part of the true Struts core. (Of course, I
 don't consider the tags part of the true Struts core either =:)
 
 I'd also be very cold on amending the struts-config with the
 specifics for any optional component, the Validator included.
 Ideally, the Validation config could be shared with other
 platforms (not just Struts), and should be a standalone file.
 
 As mentioned elsewhere, there were two classes since some
 people (or maybe one person) wanted to key on the action path
 rather than the action attribute. But if we were patch this to
 use a switch, mores the better.
 
 -Ted.
 
 10/25/2002 10:34:52 AM, David Graham [EMAIL PROTECTED]
 wrote:
 
 It struck me the 

Re: Validator Integration

[Ted Husted]

The validator is a nice piece of work but its not the only game 
in town. I agree that its a good idea to provide a default 
component for people to use, but I don't agree that it's a good 
idea to link it to the base ActionForm. 

Right now, if the Validator is not used, the code just sits 
there in the jar. But if you build it into the subclass of 
ActionForm, it gets called (even to return null) and starts to 
consume resources.

It is true that most applications need a validation step. 
That's why we have a validation hotspot. But I don't agree that 
we need to hardwire the Validator into the ActionForm. 

My true feeling is that the Validator is a fine start, but 
there is still a lot to be learned about validation, and we 
should not standardize too early. 

I'm now working on a design that pushes all the Validation back 
to the business tier. We will probably still use the Validator, 
but the Commons-Validator rather than the Struts Validator. The 
ActionForm will be use to create the business request and call 
it's validation method. The business request can then pass back 
the tokenized messages, just like the Struts validate method. 
But we end up with people working on common business classes 
that we can re-use between platforms. (Nothing out of the 
Struts jar.)

I just bring this up to point out that not everyone is just 
writing web applications or Struts applications or blindly 
using the Struts hotspots just because they are there. It's the 
job of the framework to make services available, but we need to 
be very conservative about which services we wire into our own 
*base* classes that we compell people ot use.

If nothing else, both the Validator and Tiles are proofs of 
concept about how developers can connect their own extensions 
to Struts. If we start hardwiring everything in, we start to 
loose the open aspect of the architechture. It's true that 
wiring more in would be more convenient, but there's such a 
thing as being too convenient. (A lesson Turbine learned the 
hard way.)

-Ted.


10/25/2002 1:42:20 PM, David Graham [EMAIL PROTECTED] 
wrote:

Thanks for the input Ted.  I was only suggesting changing 
struts-config if 
validator was truely merged; I agree that optional components 
don't belong 
there.  The validation rules file should be separate but I'm 
suggesting that 
the validator not be a plugin and have an entry similar to 
message-resources 
or form-beans.

Now the question is whether the validator is a core component?
I don't know what you all define as core but I believe this is 
a core 
aspect.  How many forms have you built that didn't need 
validation of at 
least one required field (if no form fields are required I 
question the 
value of the form)?

What are the various options for validation?  I see 2 built 
into Struts: 
coding a form bean's validate() method and using the 
validator.  What I'm 
suggesting is that the ActionForm.validate() method use the 
validator by 
default.

I just don't see any need to subclass a different ActionForm 
class to use 
the validator when it seems that this will become the 
predominant form of 
validation.

David






From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List struts-
[EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 13:09:10 -0400

I've been using the Validator for going on three years now, 
but
I don't think I would ever want to describe it as an integal
part of Struts. Struts provides a validation hotspot, and we
provide the Validation as something people can plug into that
spot. But we want to be very clear that it is only one of 
many
possible solutions to validation.

We provide direct support for the Validator as a convenience,
but IMHO, it is not part of the true Struts core. (Of course, 
I
don't consider the tags part of the true Struts core either 
=:)

I'd also be very cold on amending the struts-config with the
specifics for any optional component, the Validator included.
Ideally, the Validation config could be shared with other
platforms (not just Struts), and should be a standalone file.

As mentioned elsewhere, there were two classes since some
people (or maybe one person) wanted to key on the action path
rather than the action attribute. But if we were patch this 
to
use a switch, mores the better.

-Ted.

10/25/2002 10:34:52 AM, David Graham dgraham1980
@hotmail.com
wrote:

 It struck me the other day that the validator could be 
further
integrated
 into struts.  I'm not sure about my ideas so I want to get
your thoughts.  y
 Why should people need to subclass ValidatorActionForm 
instead
of ActionForm
 to use the validator?  What forms have you built that 
didn't
need
 validation?
 
 My idea is that the ValidatorActionForm and ValidatorForm 
(why
are there 2?)
 behavior should be included in ActionForm and have those
classes removed.  I
 think this will maintain backward compatibility because if 
the
developer
 

Re: Validator Integration

[David Graham]

Good points Ted.  I disagree with the resources issue.  We all know there 
are ways to avoid loading classes before they're needed.  Plus, how much 
memory does the validator use?  My guess is, not nearly enough to worry 
about.

David






From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 15:30:18 -0400

The validator is a nice piece of work but its not the only game
in town. I agree that its a good idea to provide a default
component for people to use, but I don't agree that it's a good
idea to link it to the base ActionForm.

Right now, if the Validator is not used, the code just sits
there in the jar. But if you build it into the subclass of
ActionForm, it gets called (even to return null) and starts to
consume resources.

It is true that most applications need a validation step.
That's why we have a validation hotspot. But I don't agree that
we need to hardwire the Validator into the ActionForm.

My true feeling is that the Validator is a fine start, but
there is still a lot to be learned about validation, and we
should not standardize too early.

I'm now working on a design that pushes all the Validation back
to the business tier. We will probably still use the Validator,
but the Commons-Validator rather than the Struts Validator. The
ActionForm will be use to create the business request and call
it's validation method. The business request can then pass back
the tokenized messages, just like the Struts validate method.
But we end up with people working on common business classes
that we can re-use between platforms. (Nothing out of the
Struts jar.)

I just bring this up to point out that not everyone is just
writing web applications or Struts applications or blindly
using the Struts hotspots just because they are there. It's the
job of the framework to make services available, but we need to
be very conservative about which services we wire into our own
*base* classes that we compell people ot use.

If nothing else, both the Validator and Tiles are proofs of
concept about how developers can connect their own extensions
to Struts. If we start hardwiring everything in, we start to
loose the open aspect of the architechture. It's true that
wiring more in would be more convenient, but there's such a
thing as being too convenient. (A lesson Turbine learned the
hard way.)

-Ted.


10/25/2002 1:42:20 PM, David Graham [EMAIL PROTECTED]
wrote:

Thanks for the input Ted.  I was only suggesting changing
struts-config if
validator was truely merged; I agree that optional components
don't belong
there.  The validation rules file should be separate but I'm
suggesting that
the validator not be a plugin and have an entry similar to
message-resources
or form-beans.

Now the question is whether the validator is a core component?
I don't know what you all define as core but I believe this is
a core
aspect.  How many forms have you built that didn't need
validation of at
least one required field (if no form fields are required I
question the
value of the form)?

What are the various options for validation?  I see 2 built
into Struts:
coding a form bean's validate() method and using the
validator.  What I'm
suggesting is that the ActionForm.validate() method use the
validator by
default.

I just don't see any need to subclass a different ActionForm
class to use
the validator when it seems that this will become the
predominant form of
validation.

David






From: Ted Husted [EMAIL PROTECTED]
Reply-To: Struts Developers List struts-
[EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 13:09:10 -0400

I've been using the Validator for going on three years now,
but
I don't think I would ever want to describe it as an integal
part of Struts. Struts provides a validation hotspot, and we
provide the Validation as something people can plug into that
spot. But we want to be very clear that it is only one of
many
possible solutions to validation.

We provide direct support for the Validator as a convenience,
but IMHO, it is not part of the true Struts core. (Of course,
I
don't consider the tags part of the true Struts core either
=:)

I'd also be very cold on amending the struts-config with the
specifics for any optional component, the Validator included.
Ideally, the Validation config could be shared with other
platforms (not just Struts), and should be a standalone file.

As mentioned elsewhere, there were two classes since some
people (or maybe one person) wanted to key on the action path
rather than the action attribute. But if we were patch this
to
use a switch, mores the better.

-Ted.

10/25/2002 10:34:52 AM, David Graham dgraham1980
@hotmail.com
wrote:

 It struck me the other day that the validator could be
further
integrated
 into struts.  I'm not sure about my ideas so I want to get
your thoughts.  y
 Why should 

RE: Validator Integration

[David Graham]

Actually, I think that's what I really wanted without knowing it :-).  
Struts already provides pluggable RequestProcessors for the ActionServlet, 
maybe it should allow pluggable Validators for ActionForms.  This way, we 
don't mandate the use of the commons validator or anything else, we just 
allow different implementations.

My first thought is that there could be a Validator (or ActionFormValidator, 
etc.) interface with a method like:

ActionErrors validate(ActionForm form, any other needed params);

We could provide a compliant implementation class for the commons validator. 
 Just like RequestProcessor, the validator implementation could be 
configured in struts-config.xml.

I think this addresses Ted's concerns of mandating the use of certain 
technologies because it creates a pluggable service layer.

What do you think?

David






From: James Mitchell [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Validator Integration
Date: Fri, 25 Oct 2002 15:30:09 -0400


I have no idea on the level of effort required, but it would be nice to be
able to drop in my own Validator implementation like I can logging, jdbc or
message resources.

Your thought?



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm 
not
sure about the former.
- Albert Einstein (1879-1955)




 -Original Message-
 From: David Graham [mailto:dgraham1980;hotmail.com]
 Sent: Friday, October 25, 2002 2:48 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Validator Integration


 I'm mainly suggesting this to get some new ideas out there.  I
 don't see how
 it would break backwards compatibility.  As I stated earlier, if
 a developer
 doesn't use the validator or define a validation rule for a form then 
the
 validate() method could just return null as usual.  You wouldn't have to
 override validate to maintain compatibility.  Is there something else 
I'm
 missing?

 It's not necessarily a burden to extend a different class but I do think
 it's beneficial for the framework to inherently support a high class
 validation framework without the developer being exposed to extending
 special classes.

 David






 From: Joe Germuska [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED]
 Subject: Re: Validator Integration
 Date: Fri, 25 Oct 2002 13:16:10 -0500
 
 David:
 
 we saw recently that you and I disagree on the core nature of the
 validator package.  But even if 90% of Struts users decide to
 validate with
 Validator, I don't think that's a compelling argument to change the
 behavior of ActionForm.
 
 First, doing so would break backwards compatibility.  Second, by tying
 relatively complex validation into the core class, you sort of cut off
 other possible ways to extend ActionForm.  Yes, you could argue that
 subclasses can override the validate() method and subsequently ignore
 anything in the ActionForm class which refers to validator, but
 that's not
 really very clean design.  Keep the core classes simple and
 focused on the
 minimal requirements for interacting with other objects, and add
 subclasses
 whenever more specialized behavior is needed.
 
 Is it a great burden to extend a different class if you want to use the
 validator framework to validate form input?  I do agree that having two
 separate subclasses which vary only in how they key to
 validation rules is
 unnecessarily complex, but otherwise, what benefits do such a
 change bring?
 
 Joe
 
 
 
 At 11:42 AM -0600 2002/10/25, David Graham wrote:
 Thanks for the input Ted.  I was only suggesting changing
 struts-config if
 validator was truely merged; I agree that optional components
 don't belong
 there.  The validation rules file should be separate but I'm 
suggesting
 that the validator not be a plugin and have an entry similar to
 message-resources or form-beans.
 
 Now the question is whether the validator is a core component?
 I don't know what you all define as core but I believe this is a core
 aspect.  How many forms have you built that didn't need
 validation of at
 least one required field (if no form fields are required I question 
the
 value of the form)?
 
 What are the various options for validation?  I see 2 built
 into Struts:
 coding a form bean's validate() method and using the validator.
  What I'm
 suggesting is that the ActionForm.validate() method use the
 validator by
 default.
 
 I just don't see any need to subclass a different ActionForm
 class to use
 the validator when it seems that this will become the
 predominant form of
 validation.
 
 David
 
 
 
 
 
 From: Ted Husted [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED]
 Subject: Re: Validator Integration
 Date: Fri, 25 Oct 2002 13:09:10 -0400
 
 I've been using the Validator for going on 

Re: Validator Integration

[Eddie Bush]

Sounds cool - sounds like a pretty substantial change though.  Maybe we 
could table it for now and pick it up for 2.0.x?  Of course, at that 
point, we'll have JSF coming in (most likely) and it will bring it's own 
pluggable field validators ... and what else will we need?

David Graham wrote:

Actually, I think that's what I really wanted without knowing it :-).  
Struts already provides pluggable RequestProcessors for the 
ActionServlet, maybe it should allow pluggable Validators for 
ActionForms.  This way, we don't mandate the use of the commons 
validator or anything else, we just allow different implementations.

My first thought is that there could be a Validator (or 
ActionFormValidator, etc.) interface with a method like:

ActionErrors validate(ActionForm form, any other needed params);

We could provide a compliant implementation class for the commons 
validator.  Just like RequestProcessor, the validator implementation 
could be configured in struts-config.xml.

I think this addresses Ted's concerns of mandating the use of certain 
technologies because it creates a pluggable service layer.

What do you think?

David 


--
Eddie Bush




--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[David Graham]

That's another one of my concerns.  I don't know how much JSF will replace 
the need for this.  If it doesn't, then I think this is the way to go.

David






From: Eddie Bush [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Validator Integration
Date: Fri, 25 Oct 2002 15:51:11 -0500

Sounds cool - sounds like a pretty substantial change though.  Maybe we 
could table it for now and pick it up for 2.0.x?  Of course, at that point, 
we'll have JSF coming in (most likely) and it will bring it's own pluggable 
field validators ... and what else will we need?

David Graham wrote:

Actually, I think that's what I really wanted without knowing it :-).  
Struts already provides pluggable RequestProcessors for the ActionServlet, 
maybe it should allow pluggable Validators for ActionForms.  This way, we 
don't mandate the use of the commons validator or anything else, we just 
allow different implementations.

My first thought is that there could be a Validator (or 
ActionFormValidator, etc.) interface with a method like:

ActionErrors validate(ActionForm form, any other needed params);

We could provide a compliant implementation class for the commons 
validator.  Just like RequestProcessor, the validator implementation could 
be configured in struts-config.xml.

I think this addresses Ted's concerns of mandating the use of certain 
technologies because it creates a pluggable service layer.

What do you think?

David


--
Eddie Bush




--
To unsubscribe, e-mail:   
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:struts-dev-help;jakarta.apache.org


_
Surf the Web without missing calls! Get MSN Broadband.  
http://resourcecenter.msn.com/access/plans/freeactivation.asp


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/doc/userGuide dev_validator.xml

[rleland]

rleland 2002/10/25 15:10:43

  Modified:doc/userGuide dev_validator.xml
  Log:
  Put the V back into
  David Winterfeldt name!
  
  Revision  ChangesPath
  1.10  +1 -1  jakarta-struts/doc/userGuide/dev_validator.xml
  
  Index: dev_validator.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- dev_validator.xml 25 Oct 2002 12:37:53 -  1.9
  +++ dev_validator.xml 25 Oct 2002 22:10:42 -  1.10
   -195,7 +195,7 
   section href=resources name=Validator Resources
   p
   a 
href=http://www.manning.com/getpage.html?project=hustedamp;filename=chapters.html;
  -bValidating user input/b/a by Daid Winterfeldt and Ted Husted.
  +bValidating user input/b/a by David Winterfeldt and Ted Husted.
   Sample chapter from 
   a 
href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeguidetoA/;Struts in 
Action/a; 
   available as a free download (PDF).
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml

[James Mitchell]

Speaking of David, I haven't heard from him in a while.  What gives?

James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein (1879-1955)


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:rleland;apache.org]
 Sent: Friday, October 25, 2002 6:11 PM
 To: [EMAIL PROTECTED]
 Subject: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml


 rleland 2002/10/25 15:10:43

   Modified:doc/userGuide dev_validator.xml
   Log:
   Put the V back into
   David Winterfeldt name!

   Revision  ChangesPath
   1.10  +1 -1  jakarta-struts/doc/userGuide/dev_validator.xml

   Index: dev_validator.xml
   ===
   RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
   retrieving revision 1.9
   retrieving revision 1.10
   diff -u -r1.9 -r1.10
   --- dev_validator.xml   25 Oct 2002 12:37:53 -  1.9
   +++ dev_validator.xml   25 Oct 2002 22:10:42 -  1.10
   @@ -195,7 +195,7 @@
section href=resources name=Validator Resources
p
a
 href=http://www.manning.com/getpage.html?project=hustedamp;filen
 ame=chapters.html
   -bValidating user input/b/a by Daid Winterfeldt and Ted Husted.
   +bValidating user input/b/a by David Winterfeldt and Ted Husted.
Sample chapter from
a
 href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeg
 uidetoA/Struts in Action/a;
available as a free download (PDF).




 --
 To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: Validator Integration

[Craig R. McClanahan]

On Fri, 25 Oct 2002, David Graham wrote:

 Date: Fri, 25 Oct 2002 14:58:52 -0600
 From: David Graham [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: Validator Integration

 That's another one of my concerns.  I don't know how much JSF will replace
 the need for this.  If it doesn't, then I think this is the way to go.


Component-level validation (with pluggable validators) is definitely
something that JSF will address.  However, the current design of JSF
doesn't currently have any analogue for a form bean (or the notion of a
single form-wide validate() method), so it will be interesting -- if that
is how things end up -- to see if the notion of form-level validation is
still a useful concept.

 David


Craig


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/template/util ContentMapStack.java Content.java ContentMap.java

[dgraham]

dgraham 2002/10/25 16:54:53

  Modified:src/share/org/apache/struts/taglib/template InsertTag.java
PutTag.java package.html GetTag.java
   src/share/org/apache/struts/taglib/template/util
ContentMapStack.java Content.java ContentMap.java
  Log:
  deprecated template taglib in favor of Tiles.
  
  Revision  ChangesPath
  1.13  +13 -4 
jakarta-struts/src/share/org/apache/struts/taglib/template/InsertTag.java
  
  Index: InsertTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/template/InsertTag.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- InsertTag.java14 Oct 2002 18:16:18 -  1.12
  +++ InsertTag.java25 Oct 2002 23:54:53 -  1.13
   -79,6 +79,7 
*
* author David Geary
* version $Revision$ $Date$
  + * deprecated Use Tiles instead.
*/
   public class InsertTag extends TagSupport {
   
   -103,6 +104,7 
   
  /**
* Set the template attribute. 
  + * deprecated Use Tiles instead.
*/
  public void setTemplate(String template) {
   
   -112,6 +114,7 
   
  /**
* Get the template attribute. 
  + * deprecated Use Tiles instead.
*/
  public String getTemplate() {
   
   -121,6 +124,7 
   
  /**
* Get the map attribute. 
  + * deprecated Use Tiles instead.
*/
  public ContentMap getContentMap() {
   
   -132,6 +136,7 
* Process the start tag by pushing this tag's map onto the
* content map stack. 
* See org.apache.struts.taglib.template.util.ContentMapStack.
  + * deprecated Use Tiles instead.
*/
  public int doStartTag() throws JspException {
   
   -143,6 +148,7 
   
  /**
* Process the end tag by including the template. 
  + * deprecated Use Tiles instead.
*/
  public int doEndTag() throws JspException {
   
   -169,6 +175,7 
  /**
* This method is a convenience for lt;template:putgt; tags for
* putting content into the map.
  + * deprecated Use Tiles instead.
*/
  public void put(String name, Content content) {
   
   -180,6 +187,7 
  /**
* Reset member values for reuse. This method calls super.release(),
* which invokes TagSupport.release(), which typically does nothing.
  + * deprecated Use Tiles instead.
*/
  public void release() {
   
   -195,6 +203,7 
* one present.
*
* param exception Exception to be conditionally saved
  + * deprecated Use Tiles instead.
*/
   private void saveException(Throwable exception) {
   
  
  
  
  1.10  +18 -4 
jakarta-struts/src/share/org/apache/struts/taglib/template/PutTag.java
  
  Index: PutTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/template/PutTag.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- PutTag.java   29 Apr 2001 05:34:49 -  1.9
  +++ PutTag.java   25 Oct 2002 23:54:53 -  1.10
   -75,6 +75,7 
*
* author David Geary
* version $Revision$ $Date$
  + * deprecated Use Tiles instead.
*/
   public class PutTag extends BodyTagSupport {
   
   -108,6 +109,7 
   
  /**
* Set the content name.
  + * deprecated Use Tiles instead.
*/
  public void setName(String name) { 
   
   -118,6 +120,7 
  /**
* 
* param name The role the user must be in to store content.
  + * deprecated Use Tiles instead.
*/
  public void setRole(String role) {
   
   -128,6 +131,7 
  /**
* Set the content's URI (if it's to be included) or text (if it's to
* be printed).
  + * deprecated Use Tiles instead.
*/
  public void setContent(String content) {
   
   -139,6 +143,7 
  /**
* Set direct to true, and content will be printed directly, instead
* of included (direct == false).
  + * deprecated Use Tiles instead.
*/
  public void setDirect(String direct) { 
   
   -148,6 +153,7 
   
  /**
* Get the name attribute.
  + * deprecated Use Tiles instead.
*/
  public String getName() { 
   
   -157,6 +163,7 
   
  /**
* Get the role attribute.
  + * deprecated Use Tiles instead.
*/
  public String getRole() { 
   
   -166,6 +173,7 
   
  /**
* Get the content attribute.
  + * deprecated Use Tiles instead.
*/
  public String getContent() { 
   
   -175,6 +183,7 
   
  /**
* Returns the direct attribute associated with this tag.
  + * deprecated Use Tiles instead.
*/
  public String getDirect() {
 if(hasBody()) return true;
   -187,6 +196,7 
  

cvs commit: jakarta-struts/doc/userGuide dev_template.xml

[dgraham]

dgraham 2002/10/25 17:01:05

  Modified:doc/userGuide dev_template.xml
  Log:
  added deprecation warning
  
  Revision  ChangesPath
  1.3   +4 -1  jakarta-struts/doc/userGuide/dev_template.xml
  
  Index: dev_template.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_template.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- dev_template.xml  31 Aug 2002 13:15:02 -  1.2
  +++ dev_template.xml  26 Oct 2002 00:01:05 -  1.3
   -9,7 +9,10 
   chapter name=Template Taglib Guide 
   
   section href=nested name=The Template Taglib
  -
  +p
  + bNote:/b As of Struts 1.1 the template library has been 
  + deprecated in favor of a href=dev_tiles.htmlTiles/a.
  +/p
   p
   The struts-template tag library contains tags that are useful in creating dynamic 
JSP templates for pages 
   which share a common format. These templates are best used when it is likely that a 
layout shared by several 
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java

[dgraham]

dgraham 2002/10/25 17:05:03

  Modified:src/share/org/apache/struts/taglib/html FormTag.java
  Log:
  changed POST to post
  
  Revision  ChangesPath
  1.29  +5 -5  
jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java
  
  Index: FormTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- FormTag.java  14 Oct 2002 18:16:18 -  1.28
  +++ FormTag.java  26 Oct 2002 00:05:02 -  1.29
   -550,7 +550,7 
   results.append(beanName);
   results.append(\);
   results.append( method=\);
  -results.append(method == null ? POST : method);
  +results.append(method == null ? post : method);
   results.append(\ action=\);
   results.append(response.encodeURL(getActionMappingURL()));
   results.append(\);
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13697] - Missing attributes in struts-html.tld

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13697.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13697

Missing attributes in struts-html.tld

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-26 00:21 ---
looked in 1.1b2 struts.jar and found title in struts-html.tld for both text and 
textarea tags.

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/web/validator/WEB-INF validation.xml

[jholmes]

jholmes 2002/10/25 17:25:25

  Modified:web/blank/WEB-INF struts-config.xml validation.xml
   web/example/WEB-INF validation.xml
   web/tiles-documentation/doc tutorial.jsp
   web/validator/WEB-INF validation.xml
  Log:
  change validation.xml files to reference Commons Validator DTD
  
  Revision  ChangesPath
  1.7   +0 -10 jakarta-struts/web/blank/WEB-INF/struts-config.xml
  
  Index: struts-config.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/blank/WEB-INF/struts-config.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- struts-config.xml 26 Jul 2002 13:33:08 -  1.6
  +++ struts-config.xml 26 Oct 2002 00:25:24 -  1.7
   -1,11 +1,7 
   ?xml version=1.0 encoding=ISO-8859-1 ?
   
  -
  -
   !DOCTYPE struts-config PUBLIC
  -
 -//Apache Software Foundation//DTD Struts Configuration 1.1//EN
  -
 http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd;
   
   
   -332,16 +328,10 
 !-- end comment if struts1.0.x --
   
 plug-in className=org.apache.struts.validator.ValidatorPlugIn
  -
   set-property
  -
   property=pathnames
  -
   value=/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml/
  -
 /plug-in
  -
  -
   
   /struts-config
   
  
  
  
  1.3   +2 -2  jakarta-struts/web/blank/WEB-INF/validation.xml
  
  Index: validation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/blank/WEB-INF/validation.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- validation.xml20 Oct 2002 02:13:29 -  1.2
  +++ validation.xml26 Oct 2002 00:25:24 -  1.3
   -1,8 +1,8 
   ?xml version=1.0 encoding=ISO-8859-1 ?
   
   !DOCTYPE form-validation PUBLIC
  -  -//Apache Software Foundation//DTD Struts Validation Configuration 1.1//EN
  -  http://jakarta.apache.org/struts/dtds/validation_1_1.dtd;
  +  -//Apache Software Foundation//DTD Commons Validator Rules Configuration 
1.0//EN
  +  http://jakarta.apache.org/commons/dtds/validator_1_0.dtd;
   
   form-validation
   
  
  
  
  1.6   +3 -3  jakarta-struts/web/example/WEB-INF/validation.xml
  
  Index: validation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/validation.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- validation.xml20 Oct 2002 02:13:29 -  1.5
  +++ validation.xml26 Oct 2002 00:25:24 -  1.6
   -1,8 +1,8 
   ?xml version=1.0 encoding=ISO-8859-1 ?
   
   !DOCTYPE form-validation PUBLIC
  -  -//Apache Software Foundation//DTD Struts Validation Configuration 1.1//EN
  -  http://jakarta.apache.org/struts/dtds/validation_1_1.dtd;
  +  -//Apache Software Foundation//DTD Commons Validator Rules Configuration 
1.0//EN
  +  http://jakarta.apache.org/commons/dtds/validator_1_0.dtd;
   
   !--
   Validation Rules for the Struts Example Web Application
  
  
  
  1.2   +2 -1  jakarta-struts/web/tiles-documentation/doc/tutorial.jsp
  
  Index: tutorial.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/doc/tutorial.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tutorial.jsp  6 Jul 2002 01:13:48 -   1.1
  +++ tutorial.jsp  26 Oct 2002 00:25:25 -  1.2
   -2,5 +2,6 
   % taglib uri=/WEB-INF/struts-tiles.tld prefix=tiles %
   
   tiles:insert definition=doc.mainLayout flush=true
  -  tiles:put name=body value=/doc/tutorialBody.html /
  +!--  tiles:put name=body value=/doc/tutorialBody.html / --
  +  tiles:put name=body value=/tutorial/index.jsp /
   /tiles:insert  
  
  
  
  1.5   +2 -2  jakarta-struts/web/validator/WEB-INF/validation.xml
  
  Index: validation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/validator/WEB-INF/validation.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- validation.xml20 Oct 2002 02:13:29 -  1.4
  +++ validation.xml26 Oct 2002 00:25:25 -  1.5
   -1,8 +1,8 
   ?xml version=1.0 encoding=ISO-8859-1 ?
   
   !DOCTYPE form-validation PUBLIC
  -  -//Apache Software Foundation//DTD Struts Validation Configuration 1.1//EN
  -  http://jakarta.apache.org/struts/dtds/validation_1_1.dtd;
  +  -//Apache Software Foundation//DTD Commons Validator Rules Configuration 
1.0//EN
  +  http://jakarta.apache.org/commons/dtds/validator_1_0.dtd;
   
   form-validation
  global
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 

cvs commit: jakarta-struts/doc/userGuide struts-html.xml

[dgraham]

dgraham 2002/10/25 17:34:54

  Modified:doc/userGuide struts-html.xml
  Log:
  removed accesskey attribute for html:img tag.  fixes bug #13336
  
  Revision  ChangesPath
  1.30  +0 -10 jakarta-struts/doc/userGuide/struts-html.xml
  
  Index: struts-html.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- struts-html.xml   24 Oct 2002 06:20:33 -  1.29
  +++ struts-html.xml   26 Oct 2002 00:34:54 -  1.30
   -2633,16 +2633,6 
   /info
   
   attribute
  -  nameaccesskey/name
  -  requiredfalse/required
  -  rtexprvaluetrue/rtexprvalue
  -  info
  -  pThe keyboard character used to move focus immediately
  -  to this element./p
  -  /info
  -/attribute
  -
  -attribute
 namealign/name
 requiredfalse/required
 rtexprvaluetrue/rtexprvalue
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13336] - The TLD for html:img tag has an accesskey attribute, but not supported in HTML 4.01

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13336.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13336

The TLD for html:img tag has an accesskey attribute, but not supported in HTML 4.01

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-26 00:38 ---
removed from tld in nightly build 20021026

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13929] - Missing registration for a local validation_1_1.dtd

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13929.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13929

Missing registration for a local validation_1_1.dtd

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-26 00:48 ---
Updated Struts sample validation.xml files in Struts nightly build 20021026.  
Validator registers local versions of Commons Validator DTD as of Validator 
nightly build 20021017.

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts STATUS

[dgraham]

dgraham 2002/10/25 17:57:29

  Modified:.STATUS
  Log:
  point to bugzilla query instead of tracking bugs in 2 places.
  
  Revision  ChangesPath
  1.62  +7 -1  jakarta-struts/STATUS
  
  Index: STATUS
  ===
  RCS file: /home/cvs/jakarta-struts/STATUS,v
  retrieving revision 1.61
  retrieving revision 1.62
  diff -u -r1.61 -r1.62
  --- STATUS25 Oct 2002 03:41:23 -  1.61
  +++ STATUS26 Oct 2002 00:57:28 -  1.62
   -9,6 +9,12 
   12 open bugs to swat!!
   
   
  +This file is not actively maintained.  Use this bugzilla query to see the current
  +open bugs:
  +
  
+http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+time
  +
  +
   Controller:
   --
   
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit:jakarta-struts/src/share/org/apache/struts/taglib /html FormTag.java

[Martin Cooper]

Why was this changed? The change makes Struts break compliance with the HTTP
spec, which states:

-
5.1.1 Method

The Method  token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive.
-

The method value for a post request is specified as POST, not post.

Please change this back.

--
Martin Cooper


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:dgraham;apache.org]
 Sent: Friday, October 25, 2002 5:05 PM
 To: [EMAIL PROTECTED]
 Subject: cvs commit:
 jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java
 
 
 dgraham 2002/10/25 17:05:03
 
   Modified:src/share/org/apache/struts/taglib/html FormTag.java
   Log:
   changed POST to post
   
   Revision  ChangesPath
   1.29  +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java
   
   Index: FormTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/FormTag.java,v
   retrieving revision 1.28
   retrieving revision 1.29
   diff -u -r1.28 -r1.29
   --- FormTag.java14 Oct 2002 18:16:18 -  1.28
   +++ FormTag.java26 Oct 2002 00:05:02 -  1.29
   @@ -550,7 +550,7 @@
results.append(beanName);
results.append(\);
results.append( method=\);
   -results.append(method == null ? POST : method);
   +results.append(method == null ? post : method);
results.append(\ action=\);
results.append(response.encodeURL(getActionMappingURL()));
results.append(\);
   
   
   
 
 --
 To unsubscribe, e-mail:   
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit:jakarta-struts/src/share/org/apache/struts/taglib /htmlBaseFieldTag.java BaseTag.java ButtonTag.java CancelTag.java CheckboxTag.java FrameTag.java ImageTag.java ImgTag.java MultiboxTag.javaRadio Tag.java ResetTag.java SubmitTag.java

[Martin Cooper]

Unless I'm mistaken, this commit has not yet been reverted. James (H), can
you take care of that, please?

Thanks.

--
Martin Cooper


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:jholmes;apache.org]
 Sent: Monday, October 21, 2002 3:30 PM
 To: [EMAIL PROTECTED]
 Subject: cvs commit:
 jakarta-struts/src/share/org/apache/struts/taglib/html 
 BaseFieldTag.java
 BaseTag.java ButtonTag.java CancelTag.java CheckboxTag.java
 FrameTag.java ImageTag.java ImgTag.java MultiboxTag.java RadioTag.java
 ResetTag.java SubmitTag.java
 
 
 jholmes 2002/10/21 15:30:23
 
   Modified:src/share/org/apache/struts/taglib/html 
 BaseFieldTag.java
 BaseTag.java ButtonTag.java CancelTag.java
 CheckboxTag.java FrameTag.java ImageTag.java
 ImgTag.java MultiboxTag.java RadioTag.java
 ResetTag.java SubmitTag.java
   Log:
   fix tags so that they work in text/xml mode
   
   PR: Bugzilla #12185
   
   Revision  ChangesPath
   1.14  +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/BaseFie
 ldTag.java
   
   Index: BaseFieldTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/BaseFieldTag.java,v
   retrieving revision 1.13
   retrieving revision 1.14
   diff -u -r1.13 -r1.14
   --- BaseFieldTag.java   23 Sep 2002 05:13:43 -  1.13
   +++ BaseFieldTag.java   21 Oct 2002 22:30:22 -  1.14
   @@ -192,7 +192,7 @@
results.append(\);
results.append(prepareEventHandlers());
results.append(prepareStyles());
   -results.append();
   +results.append( /);

// Print this field to our output writer
ResponseUtils.write(pageContext, results.toString());
   
   
   
   1.7   +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/BaseTag.java
   
   Index: BaseTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/BaseTag.java,v
   retrieving revision 1.6
   retrieving revision 1.7
   diff -u -r1.6 -r1.7
   --- BaseTag.java5 Oct 2002 22:56:21 -   1.6
   +++ BaseTag.java21 Oct 2002 22:30:22 -  1.7
   @@ -133,7 +133,7 @@
buf.append(target);
buf.append(\);
}
   -buf.append();
   +buf.append( /);
JspWriter out = pageContext.getOut();
try {
out.write(buf.toString());
   
   
   
   1.11  +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/ButtonTag.java
   
   Index: ButtonTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/ButtonTag.java,v
   retrieving revision 1.10
   retrieving revision 1.11
   diff -u -r1.10 -r1.11
   --- ButtonTag.java  23 Sep 2002 05:13:43 -  1.10
   +++ ButtonTag.java  21 Oct 2002 22:30:22 -  1.11
   @@ -207,7 +207,7 @@
results.append(\);
results.append(prepareEventHandlers());
results.append(prepareStyles());
   -results.append();
   +results.append( /);

// Render this element to our writer
ResponseUtils.write(pageContext, results.toString());
   
   
   
   1.7   +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/CancelTag.java
   
   Index: CancelTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/CancelTag.java,v
   retrieving revision 1.6
   retrieving revision 1.7
   diff -u -r1.6 -r1.7
   --- CancelTag.java  23 Sep 2002 05:13:43 -  1.6
   +++ CancelTag.java  21 Oct 2002 22:30:22 -  1.7
   @@ -210,7 +210,7 @@
results.append(\);
results.append(prepareEventHandlers());
results.append(prepareStyles());
   -results.append();
   +results.append( /);

// Render this element to our writer
ResponseUtils.write(pageContext, results.toString());
   
   
   
   1.13  +5 -5  
 jakarta-struts/src/share/org/apache/struts/taglib/html/Checkbo
 xTag.java
   
   Index: CheckboxTag.java
   ===
   RCS file: 
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/CheckboxTag.java,v
   retrieving revision 1.12
   retrieving revision 1.13
   diff -u -r1.12 -r1.13
   --- CheckboxTag.java23 Sep 2002 05:13:43 -  1.12
   +++ CheckboxTag.java21 Oct 2002 22:30:22 -  1.13
   @@ -217,7 +217,7 @@
results.append( checked=\checked\);
results.append(prepareEventHandlers());
results.append(prepareStyles());
 

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib /htmlFormTag.java

[David Graham]

I'm following the html 4.01 spec stated here:
http://www.w3.org/TR/html4/interact/forms.html#h-17.3

It says it's case insensitive and the example further down the page uses the 
lower case form post.  All other Struts generated attributes and elements 
are lower case so I changed this to match.

David






From: Martin Cooper [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: 'Struts Developers List' [EMAIL PROTECTED]
Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib 
/html FormTag.java
Date: Fri, 25 Oct 2002 18:06:31 -0700

Why was this changed? The change makes Struts break compliance with the 
HTTP
spec, which states:

-
5.1.1 Method

The Method  token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive.
-

The method value for a post request is specified as POST, not post.

Please change this back.

--
Martin Cooper


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:dgraham;apache.org]
 Sent: Friday, October 25, 2002 5:05 PM
 To: [EMAIL PROTECTED]
 Subject: cvs commit:
 jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java


 dgraham 2002/10/25 17:05:03

   Modified:src/share/org/apache/struts/taglib/html FormTag.java
   Log:
   changed POST to post

   Revision  ChangesPath
   1.29  +5 -5
 jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java

   Index: FormTag.java
   ===
   RCS file:
 /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/ht
ml/FormTag.java,v
   retrieving revision 1.28
   retrieving revision 1.29
   diff -u -r1.28 -r1.29
   --- FormTag.java	14 Oct 2002 18:16:18 -	1.28
   +++ FormTag.java	26 Oct 2002 00:05:02 -	1.29
   @@ -550,7 +550,7 @@
results.append(beanName);
results.append(\);
results.append( method=\);
   -results.append(method == null ? POST : method);
   +results.append(method == null ? post : method);
results.append(\ action=\);
results.append(response.encodeURL(getActionMappingURL()));
results.append(\);




 --
 To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:struts-dev-help;jakarta.apache.org


_
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml

[Martin Cooper]

 -Original Message-
 From: James Mitchell [mailto:jmitchtx;telocity.com]
 Sent: Friday, October 25, 2002 3:29 PM
 To: Struts Developers List
 Subject: RE: cvs commit: jakarta-struts/doc/userGuide 
 dev_validator.xml
 
 
 Speaking of David, I haven't heard from him in a while.  What gives?

I don't know what happened to David W - we haven't heard from him in a while
(on the list, at least). James Turner, on the other hand, is going great
guns to get Commons Validator fixed up and released. We're almost there.

--
Martin Cooper


 
 James Mitchell
 Software Engineer/Struts Evangelist
 http://www.open-tools.org
 
 Only two things are infinite, the universe and human 
 stupidity, and I'm not
 sure about the former.
 - Albert Einstein (1879-1955)
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:rleland;apache.org]
  Sent: Friday, October 25, 2002 6:11 PM
  To: [EMAIL PROTECTED]
  Subject: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml
 
 
  rleland 2002/10/25 15:10:43
 
Modified:doc/userGuide dev_validator.xml
Log:
Put the V back into
David Winterfeldt name!
 
Revision  ChangesPath
1.10  +1 -1  
 jakarta-struts/doc/userGuide/dev_validator.xml
 
Index: dev_validator.xml

 ===
RCS file: 
 /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- dev_validator.xml 25 Oct 2002 12:37:53 -  1.9
+++ dev_validator.xml 25 Oct 2002 22:10:42 -  1.10
@@ -195,7 +195,7 @@
 section href=resources name=Validator Resources
 p
 a
  href=http://www.manning.com/getpage.html?project=hustedamp;filen
  ame=chapters.html
-bValidating user input/b/a by Daid Winterfeldt and 
 Ted Husted.
+bValidating user input/b/a by David Winterfeldt 
 and Ted Husted.
 Sample chapter from
 a
  href=http://www.amazon.com/exec/obidos/ISBN=1930110502/hitchhikeg
  uidetoA/Struts in Action/a;
 available as a free download (PDF).
 
 
 
 
  --
  To unsubscribe, e-mail:
 mailto:struts-dev-unsubscribe;jakarta.apache.org
 For additional commands, e-mail: 
mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org



--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html FormTag.java

[Craig R. McClanahan]

On Fri, 25 Oct 2002, Martin Cooper wrote:

 Date: Fri, 25 Oct 2002 18:06:31 -0700
 From: Martin Cooper [EMAIL PROTECTED]
 Reply-To: Struts Developers List [EMAIL PROTECTED]
 To: 'Struts Developers List' [EMAIL PROTECTED]
 Subject: RE: cvs commit:
 jakarta-struts/src/share/org/apache/struts/taglib /html FormTag.java

 Why was this changed? The change makes Struts break compliance with the HTTP
 spec, which states:

 -
 5.1.1 Method

 The Method  token indicates the method to be performed on the resource
 identified by the Request-URI. The method is case-sensitive.
 -

 The method value for a post request is specified as POST, not post.

 Please change this back.


The value included in an HTML page (as defined in the HTML spec) has no
direct relationship with the value a browser sends on the first line of a
request (as defined in the HTTP spec).  In fact, the references to the
get and post values in the HTML spec are almost universally in lower
case.

This is not a reason to change them back (although the original upper case
values did not violate XHTML either).

 --
 Martin Cooper

Craig


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/contrib/struts-el/web/exercise-taglib bean-include.jsp index.jsp

[dmkarr]

dmkarr  2002/10/25 21:33:17

  Modified:contrib/struts-el/doc/userGuide struts-bean-el.xml
   contrib/struts-el/web/exercise-taglib bean-include.jsp
index.jsp
  Added:   contrib/struts-el/src/share/org/apache/strutsel/taglib/bean
ELIncludeTag.java ELIncludeTagBeanInfo.java
  Log:
  Bug 13788; Added bean-el:include to get access to forward functionality
  
  Revision  ChangesPath
  1.1  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELIncludeTag.java
  
  Index: ELIncludeTag.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/bean/ELIncludeTag.java,v
 1.1 2002/10/26 04:33:17 dmkarr Exp $
   * $Revision: 1.1 $
   * $Date: 2002/10/26 04:33:17 $
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2002 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowledgement:
   *   This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names The Jakarta Project, Struts, and Apache Software
   *Foundation must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called Apache
   *nor may Apache appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * http://www.apache.org/.
   *
   */
  
  package org.apache.strutsel.taglib.bean;
  
  import org.apache.struts.taglib.bean.IncludeTag;
  import javax.servlet.jsp.JspException;
  import org.apache.strutsel.taglib.utils.EvalHelper;
  import org.apache.taglibs.standard.tag.common.core.NullAttributeException;
  
  /**
   * Generate a URL-encoded include to the specified URI.
   *p
   * This class is a subclass of the class
   * codeorg.apache.struts.taglib.bean.IncludeTag/code which
   * provides most of the described functionality.  This subclass allows all
   * attribute values to be specified as expressions utilizing the JavaServer
   * Pages Standard Library expression language.
   *
   * @author David M. Karr
   * @version $Revision: 1.1 $
   */
  public class ELIncludeTag extends IncludeTag {
  
  /**
   * String value of the transaction attribute.
   */
  private String   transactionExpr;
  
  /**
   * Returns the string value of the transaction attribute.
   */
  public  String   getTransactionExpr() { return (transactionExpr); }
  
  /**
   * Sets the string value of the transaction attribute.  This attribute is
   * mapped to this method by the codeELIncludeTagBeanInfo/code class.
   */
  public  void setTransactionExpr(String transactionExpr)
  { this.transactionExpr  = transactionExpr; }
  
  /**
 

DO NOT REPLY [Bug 13788] - Struts-EL: bean:include of a forward isn't covered in Struts-EL/JSTL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13788.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13788

Struts-EL: bean:include of a forward isn't covered in Struts-EL/JSTL

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-26 04:40 ---
I added the bean-el:include tag to get access to the forward functionality.

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/logic EmptyTag.java LocalStrings.properties

[dmkarr]

dmkarr  2002/10/25 21:44:28

  Modified:src/share/org/apache/struts/taglib/logic EmptyTag.java
LocalStrings.properties
  Log:
  Bug 13940; Added error message specific to empty/notEmpty tags
  
  Revision  ChangesPath
  1.5   +5 -5  
jakarta-struts/src/share/org/apache/struts/taglib/logic/EmptyTag.java
  
  Index: EmptyTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/EmptyTag.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- EmptyTag.java 12 Oct 2002 19:19:18 -  1.4
  +++ EmptyTag.java 26 Oct 2002 04:44:28 -  1.5
   -131,7 +131,7 
   }
   } else {
   JspException e = new JspException
  -(messages.getMessage(logic.selector));
  +(messages.getMessage(empty.noNameAttribute));
   RequestUtils.saveException(pageContext, e);
   throw e;
   }
  
  
  
  1.8   +1 -0  
jakarta-struts/src/share/org/apache/struts/taglib/logic/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/LocalStrings.properties,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- LocalStrings.properties   26 Jun 2002 23:44:30 -  1.7
  +++ LocalStrings.properties   26 Oct 2002 04:44:28 -  1.8
   -1,3 +1,4 
  +empty.noNameAttribute=No name attribute was specified
   forward.forward=Exception forwarding for name {0}: {1}
   forward.lookup=Cannot find global ActionForward for name {0}
   forward.redirect=Exception redirecting for name {0}: {1}
  
  
  

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13940] - EmptyTag and NotEmptyTag uses error key logic.selector which is specific to CompareTagBase.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13940.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13940

EmptyTag and NotEmptyTag uses error key logic.selector which is specific to 
CompareTagBase.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-10-26 04:46 ---
I created a new property named empty.noNameAttribute that is specific to the
empty and notEmpty tags, indicating that the name attribute was not specified.

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml

[Rob Leland]

James Mitchell wrote:


Speaking of David, I haven't heard from him in a while.  What gives?


Don't Know, last Email he sent to the list was in July,
Sometimes life gets in the way. :-/ I emailed him today to ask if
he wanted to donate the documentation from his web site to struts
directly. We'll see.

-Rob


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

DO NOT REPLY [Bug 13985] New: - Struts-EL: html:javascript got new htmlComment attribute, so it needs to be in html-el:javascript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13985.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13985

Struts-EL: html:javascript got new htmlComment attribute, so it needs to be in 
html-el:javascript

   Summary: Struts-EL: html:javascript got new htmlComment
attribute, so it needs to be in html-el:javascript
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


As a result of changes for bug 13836, the html:javascript tag got a new
attribute, htmlComment.  This means the same attribute needs to be added to
the html-el:javascript tag.

--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

Re: [struts-el] HTML taglib

[Rob Leland]

Eddie Bush wrote:


Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. 

Just for Reference to properly build Jakarta-Commons you'll need to use
Ant 1.5.1.

-Rob


--
To unsubscribe, e-mail:   mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org

cvs commit: jakarta-struts/contrib/struts-el/doc/userGuide struts-html-el.xml

[dmkarr]

dmkarr  2002/10/25 22:24:44

  Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELJavascriptValidatorTag.java
   contrib/struts-el/doc/userGuide struts-html-el.xml
  Added:   contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELJavascriptValidatorTagBeanInfo.java
  Log:
  Bug 13985; Adding htmlComment attribute to html-el:javascript tag, also made page 
attribute check for null string
  
  Revision  ChangesPath
  1.4   +46 -9 
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELJavascriptValidatorTag.java
  
  Index: ELJavascriptValidatorTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELJavascriptValidatorTag.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ELJavascriptValidatorTag.java 1 Oct 2002 04:25:50 -   1.3
  +++ ELJavascriptValidatorTag.java 26 Oct 2002 05:24:44 -  1.4
  @@ -62,7 +62,7 @@
   
   import org.apache.struts.taglib.html.JavascriptValidatorTag;
   import javax.servlet.jsp.JspException;
  -import org.apache.taglibs.standard.tag.el.core.ExpressionUtil;
  +import org.apache.strutsel.taglib.utils.EvalHelper;
   import org.apache.taglibs.standard.tag.common.core.NullAttributeException;
   
   /**
  @@ -82,6 +82,33 @@
   public class ELJavascriptValidatorTag extends JavascriptValidatorTag {
   
   /**
  + * String value of the page attribute.
  + */
  +private String   pageExpr;
  +
  +/**
  + * Returns the string value of the page attribute.
  + */
  +public  String   getPageExpr() { return (pageExpr); }
  +
  +/**
  + * Sets the string value of the page attribute.  This attribute is mapped
  + * to this method by the codeELJavascriptValidatorTagBeanInfo/code
  + * class.
  + */
  +public  void setPageExpr(String pageExpr)
  +{ this.pageExpr  = pageExpr; }
  +
  +/**
  + * Resets attribute values for tag reuse.
  + */
  +public void release()
  +{
  +super.release();
  +setPageExpr(null);
  +}
  +
  +/**
* Process the start tag.
*
* @exception JspException if a JSP exception has occurred
  @@ -93,7 +120,8 @@
   
   /**
* Evaluates and returns a single attribute value, given the attribute
  - * name, attribute value, and attribute type.  It uses
  + * name, attribute value, and attribute type.  It uses the
  + * codeEvalHelper/code class to interface to
* codeExpressionUtil.evalNotNull/code to do the actual evaluation, and
* it passes to this the name of the current tag, the codethis/code
* pointer, and the current pageContext.
  @@ -101,6 +129,8 @@
* @param attrName attribute name being evaluated
* @param attrValue String value of attribute to be evaluated using EL
* @param attrType Required resulting type of attribute value
  + * @exception NullAttributeException if either the codeattrValue/code
  + * was null, or the resulting evaluated value was null.
* @return Resulting attribute value
*/
   private Object   evalAttr(String   attrName,
  @@ -108,8 +138,8 @@
 ClassattrType)
   throws JspException, NullAttributeException
   {
  -return (ExpressionUtil.evalNotNull(javascript, attrName, attrValue,
  -   attrType, this, pageContext));
  +return (EvalHelper.eval(javascript, attrName, attrValue, attrType,
  +this, pageContext));
   }
   
   /**
  @@ -143,7 +173,7 @@
   }
   
   try {
  -setPage(((Integer) evalAttr(page, getPage() + , Integer.class)).
  +setPage(((Integer) evalAttr(page, getPageExpr(), Integer.class)).
   intValue());
   } catch (NullAttributeException ex) {
   setPage(0);
  @@ -161,6 +191,13 @@
 String.class));
   } catch (NullAttributeException ex) {
   setStaticJavascript(null);
  +}
  +
  +try {
  +setHtmlComment((String) evalAttr(htmlComment, getHtmlComment(),
  + String.class));
  +} catch (NullAttributeException ex) {
  +setHtmlComment(null);
   }
   }
   }
  
  
  
  1.1  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELJavascriptValidatorTagBeanInfo.java
  
  Index: ELJavascriptValidatorTagBeanInfo.java
  ===
  /*
   * $Header: 

cvs commit: jakarta-struts build-all-clean.bat.sample build.properties.sample

[rleland]

rleland 2002/10/25 22:38:07

  Modified:.build-all-clean.bat.sample build.properties.sample
  Log:
  Pickup the fileupload which was moved to commons,
  and use current versions of tomcat.
  
  Revision  ChangesPath
  1.2   +3 -2  jakarta-struts/build-all-clean.bat.sample
  
  Index: build-all-clean.bat.sample
  ===
  RCS file: /home/cvs/jakarta-struts/build-all-clean.bat.sample,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build-all-clean.bat.sample16 Oct 2002 15:04:47 -  1.1
  +++ build-all-clean.bat.sample26 Oct 2002 05:38:07 -  1.2
   -57,9 +57,10 
   cd ..\validator
   call ant clean dist
   
  -cd ..\..\jakarta-commons-sandbox
   cd fileupload
   call maven
  +
  +cd ..\..\jakarta-commons-sandbox
   
   cd ..\resources
   call maven
  
  
  
  1.17  +15 -10jakarta-struts/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-struts/build.properties.sample,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- build.properties.sample   18 Oct 2002 15:20:53 -  1.16
  +++ build.properties.sample   26 Oct 2002 05:38:07 -  1.17
   -10,9 +10,7 
   # -
   
   # WARNING:  The relative paths below assume that the build.xml file is in the
  -# top-level directory of the jakarta-struts source distribution (as it still
  -# is at the moment).  If build.xml moves to under the build subdirectory,
  -# we will need to add an extra level of ../ to each of these paths.
  +# top-level directory of the jakarta-struts source distribution.
   
   # commons-lib.home Where the CVS toplevel commons live
   commons-lib.home=D:/Projects/Apache/jakarta-commons
   -25,7 +23,7 
   # is the servlet container part of this distribution), from CVS module
   # jakarta-tomcat-4.0 at jakarta.apache.org).  This is only required
   # if you are going to execute the deploy.catalina target.
  -catalina.home=${apache.home}/jakarta-tomcat-4.0.4
  +catalina.home=${apache.home}/jakarta-tomcat-4.0.6
   
   # The JAR file containing version 1.0 (or later) of the Beanutils package
   # from the Jakarta Commons project.
   -46,7 +44,7 
   
   # The JAR file containing version 1.0 (or later) of the FileUpload package
   # from the Jakarta Commons project.
  
-commons-fileupload.jar=${commons-sandbox-lib.home}/fileupload/target/commons-fileupload-1.0-dev.jar
  
+commons-fileupload.jar=${commons-lib.home}/fileupload/target/commons-fileupload-1.0-dev.jar
   
   # The JAR file containing version 1.0-b1 (or later) of the Lang package
   # from the Jakarta Commons project.
   -88,21 +86,24 
   # version 2.2 or 2.3)
   servlet.jar=${apache.home}/jakarta-servletapi/lib/servlet.jar
   
  -# The directory containing your binary distribution of Tomcat 3.2, from CVS
  +# The directory containing your binary distribution of Tomcat 3.3, from CVS
   # module jakarta-tomcat (and branch TOMCAT_32) at jakarta.apache.org.
   # This is only required if you are going to execute the deploy.tomcat target.
  -tomcat.home=${apache.home}/jakarta-tomcat-3.2.3
  +tomcat.home=${apache.home}/jakarta-tomcat-3.3.1
   
   # The JAR file containing the Xerces parser.  This is only required if you are
   # going to execute the deploy.catalina target.
   xerces.jar=${apache.home}/xerces-1_4_4/xerces.jar
   
  +# Properties related to Struts Contrib 
  +# -
  +
   # These links to the JSTL jar files are only required for building the
   # Struts-EL contrib library.  If they are not present, it will not build that
   # contrib library (although it doesn't prevent you from building it directly in
   # contrib/struts-el.
   
  -jstl.jar = 
f:/applis/jakarta-taglibs/jstl-1.0/lib/jstl.jar
  +jstl.jar = f:/applis/jakarta-taglibs/jstl-1.0/lib/jstl.jar
   jstl-standard.jar= f:/applis/jakarta-taglibs/jstl-1.0/lib/standard.jar
   
   # Properties related to Struts unit testing
   -119,6 +120,9 
   # Cactus Ant custom tasks jar
   cactus.ant.jar = ${cactus.lib}/cactus-ant.jar
   
  +# Ant Optional Jars for Junit task
  +ant.optional.jar = ${apache.home}/jakarta-ant-1.5.1/lib/optional.jar
  +
   # AspectJ from Cactus distribution
   aspectjrt.jar = ${cactus.lib}/aspectjrt.jar
   
   -127,6 +131,7 
   
   # Log4J from Jakrata-Commons
   log4j.jar = D:/Java/Programs/Apache/jakarta-log4j-1.2.6/dist/lib/log4j-1.2.6.jar
  +
   # JUnit jar file
   junit.jar = /Java/Lib/Junit3.7/junit.jar
   
   -136,5 +141,5 
   #   comment it's home property. For example, if you don't want to run the
   #   tests on Tomcat 4.0, comment the tomcat.home.40 property.
   
  -tomcat.home.32 = ${apache.home}/jakarta-tomcat-3.2.4