DO NOT REPLY [Bug 14535] - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 06:12 ---
Isn't this exactly why we have the "html:image" tag?  I think we don't need a
"src" attribute on "button" or "submit" because of that.

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

DO NOT REPLY [Bug 14535] - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 05:46 ---
Should this go in BaseHandlerTag?  The src attribute is defined for the input element, 
not just for 
button and submit inputs.  It's rather difficult determining which input elements use 
src and 
which don't; another wonderful decision from the w3c.

Why is this marked invalid?  I see the 
src attribute defined in the html spec but not for the struts tags.  I'm reopening for 
now...

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

DO NOT REPLY [Bug 14535] - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

DO NOT REPLY [Bug 14535] - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 03:41 ---
Created an attachment (id=3832)
Patch to file SubmitTag.java.

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

DO NOT REPLY [Bug 14535] - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-14 03:40 ---
Created an attachment (id=3831)
Patch for the ButtonTag.java file.

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

DO NOT REPLY [Bug 14535] New: - Add SRC attribute for html:Button and html:Submit tags.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14535

Add SRC attribute for html:Button and html:Submit tags.

   Summary: Add SRC attribute for html:Button and html:Submit tags.
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The implementation lacks of this simple attribute in the rendered button.

Patches included on the nightly build :)

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

Re: Struts 1.0.2 + Xerces 2.2.0

[Jeanfrancois Arcand]

Unfortunalty, the file doesn't contains any "--". The file is 
web-jsptaglibrary_1_2.dtd

http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd

and this is there since at least 1 year :-(  Only Xerces 2.2 fail, not 
Xerces 2.0.1, 2.0.2, 2.1.0 and Crimson.

I will have to ping the Xerces guys

-- Jeanfrancois

Eddie Bush wrote:

Yes, I've run into this too -- in my struts config files :-)  If you 
remove the unneeded "--" this error should vanish.  Examine all 
comments for occurences of "--" which do not belong (ie. do not occur 
at the start or end of the comment).

Ex:  Change anything like  to 

David Graham wrote:

Have you looked for -- within comments in the xml files your 
parsing?  The error seems pretty clear.

David 





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

Re: [VOTE] How to implement XHMTL support

[Antoni Reus]

Hi,

A Dimecres 13 Novembre 2002 23:06, David Graham va escriure:
> The developer must make a choice between html and xhtml.  This choice is
> minor as xhtml is compatible with current browsers.  Included jsps should
> not be influenced by the includer file; they must decide if they're xhtml
> or html.  That's the point behind the  tag, to  tell struts
> html library tags to render in xhtml.
>
> If you want to reuse a jsp in an html project then don't code it with xhtml
> tags.
>
> David
>
>

I don't completely agree with this:

"Included jsps should not be influenced by the includer file; they must decide 
if they're xhtml or html."

I think included jsps must not decide a thing that involves the whole request!

Anyway I  think I can see your point, included jsps should always output the 
same, xhtml or html, so you can rely on the output of the jsp, even if you 
are including it from a non-struts jsp page,.. oh well, I think now I 
completely agree with the above :-)

Salut!

-- Antoni Reus

>
>
>
>
> From: Antoni Reus <[EMAIL PROTECTED]>
>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: "Struts Developers List" <[EMAIL PROTECTED]>
> >Subject: Re: [VOTE] How to implement XHMTL support
> >Date: Wed, 13 Nov 2002 22:53:36 +0100
> >
> >Hi,
> >
> >A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure:
> > > On Wed, 13 Nov 2002, Eddie Bush wrote:
> > >
> > > 
> > >
> > > > If the outermost document is meant to enforce XHTML, how can an
> >
> >included
> >
> > > > piece *not* conform to XHTML and the entire document still be XHTML?
> >
> >I
> >
> > > > ... feel like we're attempting to over-design - but maybe I'm just
> > > > showing my own ignorance (which is something I don't think I'll ever
> > > > learn not to do - I learn way too much from being willing to do it).
> > >
> > > It can't, and that's in part what Craig pointed out. Since each
> > > included page must also be XHTML, each of those pages should state
> > > explicitly
> >
> >that
> >
> > > it is XHTML, instead of having the decision about whether or not to
> > > generate XHTML be made externally (i.e. on the topmost page). Given
> > > that the non-Struts tags on the page must also be explicitly XHTML,
> > > that
> >
> >makes
> >
> > > sense.
> >
> >The document doctype (xhtml1, html401) is global, like the character
> >encoding
> >or some response headers. There is no sense in changing the doctype flag
> > in included pages.
> >
> >If you develop a page to be included and you use tags other than
> >struts-html,
> >like  or  there is no way to reuse this page in both xhtml and
> >html, with or without , , etc 
> >but if a developer is able to create a  page to be included that only uses
> >struts-html and/or other custom tags, with the  aproach she
> >will not be able to reuse its page to generate xhtml or html
> >
> >
> >Salut!
> >
> >-- Antoni Reus
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
>
> _
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail


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

Re: [VOTE] How to implement XHMTL support

[David Graham]

The developer must make a choice between html and xhtml.  This choice is 
minor as xhtml is compatible with current browsers.  Included jsps should 
not be influenced by the includer file; they must decide if they're xhtml or 
html.  That's the point behind the  tag, to  tell struts html 
library tags to render in xhtml.

If you want to reuse a jsp in an html project then don't code it with xhtml 
tags.

David






From: Antoni Reus <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: Re: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 22:53:36 +0100

Hi,

A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure:
> On Wed, 13 Nov 2002, Eddie Bush wrote:
>
> 
>
> > If the outermost document is meant to enforce XHTML, how can an 
included
> > piece *not* conform to XHTML and the entire document still be XHTML?  
I
> > ... feel like we're attempting to over-design - but maybe I'm just
> > showing my own ignorance (which is something I don't think I'll ever
> > learn not to do - I learn way too much from being willing to do it).
>
> It can't, and that's in part what Craig pointed out. Since each included
> page must also be XHTML, each of those pages should state explicitly 
that
> it is XHTML, instead of having the decision about whether or not to
> generate XHTML be made externally (i.e. on the topmost page). Given that
> the non-Struts tags on the page must also be explicitly XHTML, that 
makes
> sense.

The document doctype (xhtml1, html401) is global, like the character 
encoding
or some response headers. There is no sense in changing the doctype flag in
included pages.

If you develop a page to be included and you use tags other than 
struts-html,
like  or  there is no way to reuse this page in both xhtml and
html, with or without , , etc 
but if a developer is able to create a  page to be included that only uses
struts-html and/or other custom tags, with the  aproach she
will not be able to reuse its page to generate xhtml or html


Salut!

-- Antoni Reus

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail


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

Re: [VOTE] How to implement XHMTL support

[Antoni Reus]

Hi, 

A Dimecres 13 Novembre 2002 20:45, Martin Cooper va escriure:
> On Wed, 13 Nov 2002, Eddie Bush wrote:
>
> 
>
> > If the outermost document is meant to enforce XHTML, how can an included
> > piece *not* conform to XHTML and the entire document still be XHTML?  I
> > ... feel like we're attempting to over-design - but maybe I'm just
> > showing my own ignorance (which is something I don't think I'll ever
> > learn not to do - I learn way too much from being willing to do it).
>
> It can't, and that's in part what Craig pointed out. Since each included
> page must also be XHTML, each of those pages should state explicitly that
> it is XHTML, instead of having the decision about whether or not to
> generate XHTML be made externally (i.e. on the topmost page). Given that
> the non-Struts tags on the page must also be explicitly XHTML, that makes
> sense.

The document doctype (xhtml1, html401) is global, like the character encoding 
or some response headers. There is no sense in changing the doctype flag in 
included pages.

If you develop a page to be included and you use tags other than struts-html, 
like  or  there is no way to reuse this page in both xhtml and 
html, with or without , , etc 
but if a developer is able to create a  page to be included that only uses 
struts-html and/or other custom tags, with the  aproach she 
will not be able to reuse its page to generate xhtml or html


Salut!

-- Antoni Reus

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

Re: Struts 1.0.2 + Xerces 2.2.0

[Eddie Bush]

Yes, I've run into this too -- in my struts config files :-)  If you 
remove the unneeded "--" this error should vanish.  Examine all comments 
for occurences of "--" which do not belong (ie. do not occur at the 
start or end of the comment).

Ex:  Change anything like  to 

David Graham wrote:

Have you looked for -- within comments in the xml files your parsing?  
The error seems pretty clear.

David 

--
Eddie Bush




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

IDE wars, was: Re: Replacing Action.* with Globals.******** README*********

[V. Cekvenich]

Eclipse +1 because of the price. Netbeans is to big.
I use Eclipse with VIM.org. VIM.org (vi) does GUI XHTML and JSP, and 
anytime I am confused and need javac. Both run in XWindows.

And only thing better than InteliJ is Omnicore CodeGuide!



.V



David Graham wrote:
I haven't shown Eclipse to one person who didn't like it.  I'm a big 
fan, but before the IDE wars start again, let me say that it doesn't do 
jsp highlighting or jsp code completion out of the box.  I understand 
NetBeans does and that's a plus.

Dave






From: "James Mitchell" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: Replacing Action.* with Globals. README *
Date: Tue, 12 Nov 2002 20:21:26 -0500

I must admit.  Since the hoopla a few weeks ago about Eclipse this and
Eclipse that..I decided to download it and try it 
out..WOW!!!  I
was a big NetBeans advocate, but now I'm hooked on Eclipse and I haven't
looked back since.

Can you believe how it resolves the import statements?  Hell, you can 
just
delete them all, then select 'Organize Imports' and it will rip 
through the
classpath and group and fix all imports to what they should have
beencome on.you gotta love that.

My personal favoriteHierarchy view, just F4 on a class, package, or
source folder and you get an instant overview (inheritance hieratical
treeview) from java.lang.Object to lowest subclass.who needs a 
diagram
when you've got this?


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

"If you were plowing a field, which would you rather use? Two strong 
oxen or
1024 chickens?"
- Seymour Cray (1925-1996), father of supercomputing


> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Tuesday, November 12, 2002 6:43 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Replacing Action.* with Globals. README *
>
>
> +1 on separating formatting from code changes.  In my defense, 
several of
> the files had import javax.servlet.* which violates the current import
> practice (a practice I disagree with but follow nonetheless).
> Also, some of
> the imports were no longer needed and Eclipse removed them.  The
> tiles code
> in particular did not follow the java standard coding guidelines so I
> formatted those as well.
>
> I apologize for the inconvenience; from now on, I'll commit appropriate
> formatting changes separately.
>
> Dave
>
>
>
>
> >From: "James Mitchell" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: "Struts Developers List" <[EMAIL PROTECTED]>
> >Subject: RE: Replacing Action.* with Globals. README *
> >Date: Tue, 12 Nov 2002 16:06:22 -0500
> >
> >Since we are all bashing David (LOL...just kidding), may I make one 
more
> >suggestion.
> >
> >Can we all agree to separate code changes with format changes?
> >
> >I usually check every commit to see if it impacts something I might be
> >working on (bug fix or personal dev) and as I was browsing my mail 
this
> >morning, I found that reading through a couple of "recent
> commits " 
> >was giving me a migraine.  Finding the actual code changes was
> impossible.
> >
> >In fact, we probably should not be using our IDE's 'reformat' features
> >unless the current page formatting is complete crap.  If we each 
reformat
> >every time we open and change a file.  We will see battles
> emerging between
> >JBuilder, NetBeans, Eclipse, and others.
> >
> >If that sounds feasible, I would also recommend to those of us just 
using
> >text editors to turn off the 'trim trailing spaces' when saving.  This
> >causes just as much of a headache.
> >
> >Your thoughts?
> >
> >
> >
> >James Mitchell
> >Software Engineer/Struts Evangelist
> >http://www.open-tools.org
> >
> >"If you were plowing a field, which would you rather use? Two
> strong oxen
> >or
> >1024 chickens?"
> >- Seymour Cray (1925-1996), father of supercomputing
> >
> >
> > > -Original Message-
> > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > Sent: Tuesday, November 12, 2002 12:10 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Replacing Action.* with Globals.*
> > >
> > >
> > > You are right.  I didn't wait long enough because I was making
> > > other changes
> > > and didn't want to get confused about which ones to commit.
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: "Martin Cooper" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >To: "'Struts Developers List'" <[EMAIL PROTECTED]>
> > > >Subject: RE: Replacing Action.* with Globals.*
> > > >Date: Tue, 12 Nov 2002 08:49:49 -0800
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > > Sent: Tuesday, November 12, 2002 8:30 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: Replacing Action.* wit

Re: Replacing Action.* with Globals.******** README *********

[Erik Hatcher]

Just be sure to be seated if you ever decide to give IDEA IntelliJ a try 
if you get that excited about measley little import cleanup :))

Don't get me wrong, Eclipse is cool and the price is nice.  But 
IntelliJ thats where its at :)

James Mitchell wrote:
I must admit.  Since the hoopla a few weeks ago about Eclipse this and
Eclipse that..I decided to download it and try it out..WOW!!!  I
was a big NetBeans advocate, but now I'm hooked on Eclipse and I haven't
looked back since.

Can you believe how it resolves the import statements?  Hell, you can just
delete them all, then select 'Organize Imports' and it will rip through the
classpath and group and fix all imports to what they should have
beencome on.you gotta love that.

My personal favoriteHierarchy view, just F4 on a class, package, or
source folder and you get an instant overview (inheritance hieratical
treeview) from java.lang.Object to lowest subclass.who needs a diagram
when you've got this?


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

"If you were plowing a field, which would you rather use? Two strong oxen or
1024 chickens?"
- Seymour Cray (1925-1996), father of supercomputing




-Original Message-
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Tuesday, November 12, 2002 6:43 PM
To: [EMAIL PROTECTED]
Subject: RE: Replacing Action.* with Globals. README *


+1 on separating formatting from code changes.  In my defense, several of
the files had import javax.servlet.* which violates the current import
practice (a practice I disagree with but follow nonetheless).
Also, some of
the imports were no longer needed and Eclipse removed them.  The
tiles code
in particular did not follow the java standard coding guidelines so I
formatted those as well.

I apologize for the inconvenience; from now on, I'll commit appropriate
formatting changes separately.

Dave






From: "James Mitchell" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: Replacing Action.* with Globals. README *
Date: Tue, 12 Nov 2002 16:06:22 -0500

Since we are all bashing David (LOL...just kidding), may I make one more
suggestion.

Can we all agree to separate code changes with format changes?

I usually check every commit to see if it impacts something I might be
working on (bug fix or personal dev) and as I was browsing my mail this
morning, I found that reading through a couple of "recent


commits " 


was giving me a migraine.  Finding the actual code changes was


impossible.


In fact, we probably should not be using our IDE's 'reformat' features
unless the current page formatting is complete crap.  If we each reformat
every time we open and change a file.  We will see battles


emerging between


JBuilder, NetBeans, Eclipse, and others.

If that sounds feasible, I would also recommend to those of us just using
text editors to turn off the 'trim trailing spaces' when saving.  This
causes just as much of a headache.

Your thoughts?



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

"If you were plowing a field, which would you rather use? Two


strong oxen


or
1024 chickens?"
- Seymour Cray (1925-1996), father of supercomputing




-Original Message-
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Tuesday, November 12, 2002 12:10 PM
To: [EMAIL PROTECTED]
Subject: RE: Replacing Action.* with Globals.*


You are right.  I didn't wait long enough because I was making
other changes
and didn't want to get confused about which ones to commit.

David








From: "Martin Cooper" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Subject: RE: Replacing Action.* with Globals.*
Date: Tue, 12 Nov 2002 08:49:49 -0800





-Original Message-
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Tuesday, November 12, 2002 8:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Replacing Action.* with Globals.*


I committed the updates last night because I didn't hear
anyone complain.


I don't have a problem with the changes.

I would like to point out, however, that you only waited 3 hours for
feedback. Not all of us are in the same country, let alone the same



time


zone. Cedric, for example, had no hope of responding in



time, unless he


happened to be reading Struts mail at around 3am his time (my



estimate).


Even those of us in an appropriate time zone are not all constantly
checking
mail to struts-dev.

Given your statement that you "would hate to do this and



have to back


out


the changes" (which I understand :), I would suggest that you


might want to


allow more time for people to respond before going ahead with


changes like


this. Otherwise, you do leave yourself open to having to back out the
changes.

--
Martin Cooper




David

Re: Struts 1.0.2 + Xerces 2.2.0

[David Graham]

Have you looked for -- within comments in the xml files your parsing?  The 
error seems pretty clear.

David






From: Jeanfrancois Arcand <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Struts 1.0.2 + Xerces 2.2.0
Date: Tue, 12 Nov 2002 17:03:29 -0500

HI,

we (the Tomcat dev team) are experiencing some problem with Struts 1.0.2 
and Xerces 2.2.0 in Tomcat. When starting Tomcat, a wrong exception is 
thrown (see below). Is somedoby aware of a similar problem? I'm trying to 
produce a smaller test case for the Xerces-J team (they will not fix the 
bug until I produce a smaller test case :-( ). I have make some tests and 
the problem doesn't seems to come from the Digester, but directly from 
Xerces.

Any help will be appreciated.

-- Jeanfrancois

Parse Fatal Error at line 551 column 44: The string "--" is not permitted 
within comments
.
org.xml.sax.SAXParseException: The string "--" is not permitted within 
comments.
at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Sou
rce)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown 
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown 
Source)
at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown 
Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown 
Source)

at 
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown 
S
ource)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Sou
rce)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown 
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown 
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown 
Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.struts.digester.Digester.parse(Digester.java:755)


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


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

RE: Struts 1.0.2 + Xerces 2.2.0

[Karr, David]

This is not a bug.  It's part of the XML specification.

http://www.w3.org/TR/REC-xml#sec-comments

> -Original Message-
> From: Jeanfrancois Arcand [mailto:jfarcand@;apache.org]
> 
> we (the Tomcat dev team) are experiencing some problem with 
> Struts 1.0.2 
> and Xerces 2.2.0 in Tomcat. When starting Tomcat, a wrong 
> exception is 
> thrown (see below). Is somedoby aware of a similar problem? 
> I'm trying 
> to produce a smaller test case for the Xerces-J team (they 
> will not fix 
> the bug until I produce a smaller test case :-( ). I have make some 
> tests and the problem doesn't seems to come from the Digester, but 
> directly from Xerces.
> 
> Any help will be appreciated.
> 
> -- Jeanfrancois
> 
> Parse Fatal Error at line 551 column 44: The string "--" is not 
> permitted within comments
> .
> org.xml.sax.SAXParseException: The string "--" is not 
> permitted within 
> comments.

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

Struts 1.0.2 + Xerces 2.2.0

[Jeanfrancois Arcand]

HI,

we (the Tomcat dev team) are experiencing some problem with Struts 1.0.2 
and Xerces 2.2.0 in Tomcat. When starting Tomcat, a wrong exception is 
thrown (see below). Is somedoby aware of a similar problem? I'm trying 
to produce a smaller test case for the Xerces-J team (they will not fix 
the bug until I produce a smaller test case :-( ). I have make some 
tests and the problem doesn't seems to come from the Digester, but 
directly from Xerces.

Any help will be appreciated.

-- Jeanfrancois

Parse Fatal Error at line 551 column 44: The string "--" is not 
permitted within comments
.
org.xml.sax.SAXParseException: The string "--" is not permitted within 
comments.
at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Sou
rce)
at 
org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown 
Source)
at org.apache.xerces.impl.XMLScanner.scanComment(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanComment(Unknown 
Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown 
Source)

at 
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown 
S
ource)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Sou
rce)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown 
Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.struts.digester.Digester.parse(Digester.java:755)


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

RE: [VOTE] How to implement XHMTL support

[David Graham]

The future of the struts html tags is unclear.  JavaServer Faces will 
largely replace their functionality.  I just wanted to get simple xhtml 
support into Struts now because it's a requirement on some projects.  It's 
easy enough to setup xhtml with the current nightly builds and enhancements 
I'll be making over the next few days.

David






From: "Hajratwala, Nayan (N.)" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Subject: RE: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 15:18:57 -0500

I think it would be worth investigating whether or not XHTML is fully 
backward compatible with HTML 4.01 (which i think it is), and then ONLY 
rendering XHTML, and forgetting about HTML altogether.  Of course, this 
would have the be a version 2.0 enhancement because it would likely break 
some people's pages.

Anyone agree?

---
- Nayan Hajratwala
- Chikli Consulting LLC
- http://www.chikli.com


-Original Message-
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Wednesday, November 13, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] How to implement XHMTL support


Ok, I think I agree with the non-body tag setting a page scoped attribute.
I really like the style of  over .  The "is"
part indicates that it's a question rather than stating that we're using
xhtml.

Regardless, I'll get the changes in soon so people can start playing with
it.

David






>From: Martin Cooper <[EMAIL PROTECTED]>
>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>To: Struts Developers List <[EMAIL PROTECTED]>
>Subject: RE: [VOTE] How to implement XHMTL support
>Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST)
>
>
>
>On Wed, 13 Nov 2002, David Graham wrote:
>
> > What would  do?
>
>This would be the way Craig was seeking for an included page to tell its
>own Struts tags whether to render XHTML or plain HTML. It would set a
>*page* context attribute, which the subsequent tags on that page would
>check.
>
>As a corollary, the  tag should set the key in
>*page* scope rather than request scope, so that each page has to make its
>own decision.
>
> >
> > If we're going to use a tag I think it should be like this:
> > 
> >   
> >  
> >   
> > 
>
>Do you mean a separate tag from the  tag, instead of using
>, or are you referring to another tag for the
>XHTML-ness ;-) of the content? If the former, I'm not sure why we would
>want that. If the latter, I disagree that it should be a body tag, since
>it needs to be an all-or-nothing tag, not one that applies only to its
>body.
>
> >
> > Any tag inside  would be rendered as xhtml.  This tag 
would
>only
> > be useful for jsp included files.
> >
> > Another question: what if  is nested inside
> > ?
>
>I think we should probably log a warning. In many cases, the resulting
>output will work, but we need to flag that there's a potential problem.
>
>--
>Martin Cooper
>
>
> >
> > David
> >
> >
> >
> >
> >
> >
> > >From: Martin Cooper <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: Struts Developers List <[EMAIL PROTECTED]>
> > >Subject: RE: [VOTE] How to implement XHMTL support
> > >Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST)
> > >
> > >
> > >
> > >On Wed, 13 Nov 2002, David Graham wrote:
> > >
> > > > What if we just forgot about the  tag altogether?  If 
an
> > > > included jsp wants to use xhtml they can set the Globals.XHTML_KEY
> > >request
> > > > parameter to true.
> > >
> > >How would you propose to do that without using scriptlets, and 
without
> > >"knowing" the value of the key?
> > >
> > >I think perhaps a  tag is the most straightforward
> > >solution.
> > >
> > >--
> > >Martin Cooper
> > >
> > >
> > > >
> > > > Keep in mind that the currently implemented solution works for
>people
> > >using
> > > >  in a jsp and for people using tiles where they can 
have
>a
> > > > layout.jsp like this:
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > What's left is how to accomodate people using jsp includes.  What 
do
>you
> > > > think?
> > > >
> > > > David
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >From: "Karr, David" <[EMAIL PROTECTED]>
> > > > >Reply-To: "Struts Developers List" 
<[EMAIL PROTECTED]>
> > > > >To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > > >Date: Wed, 13 Nov 2002 10:06:56 -0800
> > > > >
> > > > > > -Original Message-
> > > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > > >
> > > > > > What if we did this:
> > > > > > 1.  Store a boolean in the request under Globals.XHTML_KEY
> > > > > > 2.   would set the boolean to true
> > > > > > 3.   (new tag) would set the boolean to true
> > > > > > 4.  People could manually set the request attribute if they
> > > > > > choose and
> > > > > > realize potential problems.
> > > > > >
> > > > > > This frees you from using , and allows included
> > > > > > jsps to set 

RE: [VOTE] How to implement XHMTL support

[Hajratwala, Nayan (N.)]

I think it would be worth investigating whether or not XHTML is fully backward 
compatible with HTML 4.01 (which i think it is), and then ONLY rendering XHTML, and 
forgetting about HTML altogether.  Of course, this would have the be a version 2.0 
enhancement because it would likely break some people's pages.

Anyone agree?

---
- Nayan Hajratwala
- Chikli Consulting LLC
- http://www.chikli.com


-Original Message-
From: David Graham [mailto:dgraham1980@;hotmail.com]
Sent: Wednesday, November 13, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] How to implement XHMTL support


Ok, I think I agree with the non-body tag setting a page scoped attribute.  
I really like the style of  over .  The "is" 
part indicates that it's a question rather than stating that we're using 
xhtml.

Regardless, I'll get the changes in soon so people can start playing with 
it.

David






>From: Martin Cooper <[EMAIL PROTECTED]>
>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>To: Struts Developers List <[EMAIL PROTECTED]>
>Subject: RE: [VOTE] How to implement XHMTL support
>Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST)
>
>
>
>On Wed, 13 Nov 2002, David Graham wrote:
>
> > What would  do?
>
>This would be the way Craig was seeking for an included page to tell its
>own Struts tags whether to render XHTML or plain HTML. It would set a
>*page* context attribute, which the subsequent tags on that page would
>check.
>
>As a corollary, the  tag should set the key in
>*page* scope rather than request scope, so that each page has to make its
>own decision.
>
> >
> > If we're going to use a tag I think it should be like this:
> > 
> >   
> >  
> >   
> > 
>
>Do you mean a separate tag from the  tag, instead of using
>, or are you referring to another tag for the
>XHTML-ness ;-) of the content? If the former, I'm not sure why we would
>want that. If the latter, I disagree that it should be a body tag, since
>it needs to be an all-or-nothing tag, not one that applies only to its
>body.
>
> >
> > Any tag inside  would be rendered as xhtml.  This tag would 
>only
> > be useful for jsp included files.
> >
> > Another question: what if  is nested inside
> > ?
>
>I think we should probably log a warning. In many cases, the resulting
>output will work, but we need to flag that there's a potential problem.
>
>--
>Martin Cooper
>
>
> >
> > David
> >
> >
> >
> >
> >
> >
> > >From: Martin Cooper <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: Struts Developers List <[EMAIL PROTECTED]>
> > >Subject: RE: [VOTE] How to implement XHMTL support
> > >Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST)
> > >
> > >
> > >
> > >On Wed, 13 Nov 2002, David Graham wrote:
> > >
> > > > What if we just forgot about the  tag altogether?  If an
> > > > included jsp wants to use xhtml they can set the Globals.XHTML_KEY
> > >request
> > > > parameter to true.
> > >
> > >How would you propose to do that without using scriptlets, and without
> > >"knowing" the value of the key?
> > >
> > >I think perhaps a  tag is the most straightforward
> > >solution.
> > >
> > >--
> > >Martin Cooper
> > >
> > >
> > > >
> > > > Keep in mind that the currently implemented solution works for 
>people
> > >using
> > > >  in a jsp and for people using tiles where they can have 
>a
> > > > layout.jsp like this:
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > What's left is how to accomodate people using jsp includes.  What do 
>you
> > > > think?
> > > >
> > > > David
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >From: "Karr, David" <[EMAIL PROTECTED]>
> > > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > > >To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > > >Date: Wed, 13 Nov 2002 10:06:56 -0800
> > > > >
> > > > > > -Original Message-
> > > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > > >
> > > > > > What if we did this:
> > > > > > 1.  Store a boolean in the request under Globals.XHTML_KEY
> > > > > > 2.   would set the boolean to true
> > > > > > 3.   (new tag) would set the boolean to true
> > > > > > 4.  People could manually set the request attribute if they
> > > > > > choose and
> > > > > > realize potential problems.
> > > > > >
> > > > > > This frees you from using , and allows included
> > > > > > jsps to set their
> > > > > > xhtml status independently of the outer page.
> > > > > >
> > > > > > Does this accomodate everyone's needs?
> > > > >
> > > > >Well, I have no "needs" for this, just opinions :) .
> > > > >
> > > > >Despite the simplicity of "html:xhtml", I think the name should be 
>a
> > > > >little more different from "html:html".  I used the example of
> > > > >"html:useXhtml" to try to make it clearer that the tag isn't 
>generating
> > > > >a HTML tag, and is pretty different from "html:html".
> > > > >
> > > > >Also (from your other note), if any tags nested (even through
> > > 

DO NOT REPLY [Bug 14524] New: - Struts custom tags do not work reset the attributes under the tomcat 4.1.12

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14524

Struts custom tags do not work reset the attributes under the tomcat 4.1.12

   Summary: Struts custom tags do not work reset the attributes
under the tomcat 4.1.12
   Product: Struts
   Version: 1.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the  tag, the tag attributes are reset in the tag handler "release
()". However, Tomcat 4.1.12 strictly follows the spec to manage the custom tag 
lifecycle which will not invoke the handler "release" until the end of the jsp 
page. That is, if a struts custom tag is used more than once in a jsp page, 
then the attributes may be automcatically carried from the first tag to the 
second one.

For example, 





The second form tag will use the name from the first form tag instead of 
reading from struts-config.xml.

I also noticed that all the struts tag have the similiar problem.

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

RE: [VOTE] How to implement XHMTL support

[Karr, David]

Neither am I.  Absolutely correct naming is almost impossible, it's just
a good goal.  If you can't make it perfect, the documentation should
take you the rest of the way.  Make sure that the documentation for the
"html" and "xhtml" tags refer to each other.  A boilerplate comment
about this in each HTML tag might be useful also.

> -Original Message-
> From: Martin Cooper [mailto:martinc@;apache.org]
> 
> On Wed, 13 Nov 2002, David Graham wrote:
> 
> > Ok, I think I agree with the non-body tag setting a page 
> scoped attribute.
> > I really like the style of  over 
> .  The "is"
> > part indicates that it's a question rather than stating 
> that we're using
> > xhtml.
> 
> I'm not that fussed about the name - isXhtml, useXhtml, or 
> just xhtml. I
> do agree with David Karr that just xhtml is rather subtle, but I'm not
> going to veto it. ;-)

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

Re: [VOTE] How to implement XHMTL support

[Eddie Bush]

Martin Cooper wrote:


On Wed, 13 Nov 2002, Eddie Bush wrote:




If the outermost document is meant to enforce XHTML, how can an included
piece *not* conform to XHTML and the entire document still be XHTML?  I
... feel like we're attempting to over-design - but maybe I'm just
showing my own ignorance (which is something I don't think I'll ever
learn not to do - I learn way too much from being willing to do it).
   

It can't, and that's in part what Craig pointed out. Since each included
page must also be XHTML, each of those pages should state explicitly that
it is XHTML, instead of having the decision about whether or not to
generate XHTML be made externally (i.e. on the topmost page). Given that
the non-Struts tags on the page must also be explicitly XHTML, that makes
sense.


Ah - so the tag would serve to say "This is XHTML-compliant" so that you 
could then say "Wait a sec - you asked for an XHTML document - but you 
included this and it's not XHTML".  I think I understand the reasoning 
better now.  Sorry about being so thick-headed.

I figured I was confuzzled, but I wanted to be clear.  Thanks Martin ;-)

--
Martin Cooper


--
Eddie Bush


--
Eddie Bush




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

RE: [VOTE] How to implement XHMTL support

[Martin Cooper]

On Wed, 13 Nov 2002, David Graham wrote:

> Ok, I think I agree with the non-body tag setting a page scoped attribute.
> I really like the style of  over .  The "is"
> part indicates that it's a question rather than stating that we're using
> xhtml.

I'm not that fussed about the name - isXhtml, useXhtml, or just xhtml. I
do agree with David Karr that just xhtml is rather subtle, but I'm not
going to veto it. ;-)

--
Martin Cooper


 >
> Regardless, I'll get the changes in soon so people can start playing with
> it.
>
> David
>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: RE: [VOTE] How to implement XHMTL support
> >Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST)
> >
> >
> >
> >On Wed, 13 Nov 2002, David Graham wrote:
> >
> > > What would  do?
> >
> >This would be the way Craig was seeking for an included page to tell its
> >own Struts tags whether to render XHTML or plain HTML. It would set a
> >*page* context attribute, which the subsequent tags on that page would
> >check.
> >
> >As a corollary, the  tag should set the key in
> >*page* scope rather than request scope, so that each page has to make its
> >own decision.
> >
> > >
> > > If we're going to use a tag I think it should be like this:
> > > 
> > >   
> > >  
> > >   
> > > 
> >
> >Do you mean a separate tag from the  tag, instead of using
> >, or are you referring to another tag for the
> >XHTML-ness ;-) of the content? If the former, I'm not sure why we would
> >want that. If the latter, I disagree that it should be a body tag, since
> >it needs to be an all-or-nothing tag, not one that applies only to its
> >body.
> >
> > >
> > > Any tag inside  would be rendered as xhtml.  This tag would
> >only
> > > be useful for jsp included files.
> > >
> > > Another question: what if  is nested inside
> > > ?
> >
> >I think we should probably log a warning. In many cases, the resulting
> >output will work, but we need to flag that there's a potential problem.
> >
> >--
> >Martin Cooper
> >
> >
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: Martin Cooper <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >To: Struts Developers List <[EMAIL PROTECTED]>
> > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > >Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST)
> > > >
> > > >
> > > >
> > > >On Wed, 13 Nov 2002, David Graham wrote:
> > > >
> > > > > What if we just forgot about the  tag altogether?  If an
> > > > > included jsp wants to use xhtml they can set the Globals.XHTML_KEY
> > > >request
> > > > > parameter to true.
> > > >
> > > >How would you propose to do that without using scriptlets, and without
> > > >"knowing" the value of the key?
> > > >
> > > >I think perhaps a  tag is the most straightforward
> > > >solution.
> > > >
> > > >--
> > > >Martin Cooper
> > > >
> > > >
> > > > >
> > > > > Keep in mind that the currently implemented solution works for
> >people
> > > >using
> > > > >  in a jsp and for people using tiles where they can have
> >a
> > > > > layout.jsp like this:
> > > > >
> > > > > 
> > > > >
> > > > > 
> > > > >
> > > > > What's left is how to accomodate people using jsp includes.  What do
> >you
> > > > > think?
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >From: "Karr, David" <[EMAIL PROTECTED]>
> > > > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > > > >To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > > > >Date: Wed, 13 Nov 2002 10:06:56 -0800
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > > > >
> > > > > > > What if we did this:
> > > > > > > 1.  Store a boolean in the request under Globals.XHTML_KEY
> > > > > > > 2.   would set the boolean to true
> > > > > > > 3.   (new tag) would set the boolean to true
> > > > > > > 4.  People could manually set the request attribute if they
> > > > > > > choose and
> > > > > > > realize potential problems.
> > > > > > >
> > > > > > > This frees you from using , and allows included
> > > > > > > jsps to set their
> > > > > > > xhtml status independently of the outer page.
> > > > > > >
> > > > > > > Does this accomodate everyone's needs?
> > > > > >
> > > > > >Well, I have no "needs" for this, just opinions :) .
> > > > > >
> > > > > >Despite the simplicity of "html:xhtml", I think the name should be
> >a
> > > > > >little more different from "html:html".  I used the example of
> > > > > >"html:useXhtml" to try to make it clearer that the tag isn't
> >generating
> > > > > >a HTML tag, and is pretty different from "html:html".
> > > > > >
> > > > > >Also (from your other note), if any tags nested (even through
> > > > > >"jsp:include") in  will NOT use xhtml,
> >then
> > > > > >that implies 

Re: [VOTE] How to implement XHMTL support

[Martin Cooper]

On Wed, 13 Nov 2002, Eddie Bush wrote:



> If the outermost document is meant to enforce XHTML, how can an included
> piece *not* conform to XHTML and the entire document still be XHTML?  I
> ... feel like we're attempting to over-design - but maybe I'm just
> showing my own ignorance (which is something I don't think I'll ever
> learn not to do - I learn way too much from being willing to do it).

It can't, and that's in part what Craig pointed out. Since each included
page must also be XHTML, each of those pages should state explicitly that
it is XHTML, instead of having the decision about whether or not to
generate XHTML be made externally (i.e. on the topmost page). Given that
the non-Struts tags on the page must also be explicitly XHTML, that makes
sense.

--
Martin Cooper


>
> --
> Eddie Bush
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

RE: [VOTE] How to implement XHMTL support

[David Graham]

Ok, I think I agree with the non-body tag setting a page scoped attribute.  
I really like the style of  over .  The "is" 
part indicates that it's a question rather than stating that we're using 
xhtml.

Regardless, I'll get the changes in soon so people can start playing with 
it.

David






From: Martin Cooper <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: RE: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 11:10:29 -0800 (PST)



On Wed, 13 Nov 2002, David Graham wrote:

> What would  do?

This would be the way Craig was seeking for an included page to tell its
own Struts tags whether to render XHTML or plain HTML. It would set a
*page* context attribute, which the subsequent tags on that page would
check.

As a corollary, the  tag should set the key in
*page* scope rather than request scope, so that each page has to make its
own decision.

>
> If we're going to use a tag I think it should be like this:
> 
>   
>  
>   
> 

Do you mean a separate tag from the  tag, instead of using
, or are you referring to another tag for the
XHTML-ness ;-) of the content? If the former, I'm not sure why we would
want that. If the latter, I disagree that it should be a body tag, since
it needs to be an all-or-nothing tag, not one that applies only to its
body.

>
> Any tag inside  would be rendered as xhtml.  This tag would 
only
> be useful for jsp included files.
>
> Another question: what if  is nested inside
> ?

I think we should probably log a warning. In many cases, the resulting
output will work, but we need to flag that there's a potential problem.

--
Martin Cooper


>
> David
>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: RE: [VOTE] How to implement XHMTL support
> >Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST)
> >
> >
> >
> >On Wed, 13 Nov 2002, David Graham wrote:
> >
> > > What if we just forgot about the  tag altogether?  If an
> > > included jsp wants to use xhtml they can set the Globals.XHTML_KEY
> >request
> > > parameter to true.
> >
> >How would you propose to do that without using scriptlets, and without
> >"knowing" the value of the key?
> >
> >I think perhaps a  tag is the most straightforward
> >solution.
> >
> >--
> >Martin Cooper
> >
> >
> > >
> > > Keep in mind that the currently implemented solution works for 
people
> >using
> > >  in a jsp and for people using tiles where they can have 
a
> > > layout.jsp like this:
> > >
> > > 
> > >
> > > 
> > >
> > > What's left is how to accomodate people using jsp includes.  What do 
you
> > > think?
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: "Karr, David" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > >Date: Wed, 13 Nov 2002 10:06:56 -0800
> > > >
> > > > > -Original Message-
> > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > >
> > > > > What if we did this:
> > > > > 1.  Store a boolean in the request under Globals.XHTML_KEY
> > > > > 2.   would set the boolean to true
> > > > > 3.   (new tag) would set the boolean to true
> > > > > 4.  People could manually set the request attribute if they
> > > > > choose and
> > > > > realize potential problems.
> > > > >
> > > > > This frees you from using , and allows included
> > > > > jsps to set their
> > > > > xhtml status independently of the outer page.
> > > > >
> > > > > Does this accomodate everyone's needs?
> > > >
> > > >Well, I have no "needs" for this, just opinions :) .
> > > >
> > > >Despite the simplicity of "html:xhtml", I think the name should be 
a
> > > >little more different from "html:html".  I used the example of
> > > >"html:useXhtml" to try to make it clearer that the tag isn't 
generating
> > > >a HTML tag, and is pretty different from "html:html".
> > > >
> > > >Also (from your other note), if any tags nested (even through
> > > >"jsp:include") in  will NOT use xhtml, 
then
> > > >that implies that the other tag also needs a "true/false" 
attribute, as
> > > >opposed to having no attributes (which would imply the tag's 
presence
> > > >implies "true").
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> > > >
> > > >For additional commands, e-mail:
> > > >
> > >
> > >
> > > _
> > > Tired of spam? Get advanced junk mail protection with MSN 8.
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > > For additional commands, e-mail:
> >
> > >
> > >
> >

Re: [VOTE] How to implement XHMTL support

[Eddie Bush]

Martin Cooper wrote:


On Wed, 13 Nov 2002, David Graham wrote:


What would  do?
   

This would be the way Craig was seeking for an included page to tell its
own Struts tags whether to render XHTML or plain HTML. It would set a
*page* context attribute, which the subsequent tags on that page would
check.

As a corollary, the  tag should set the key in
*page* scope rather than request scope, so that each page has to make its
own decision.


If we're going to use a tag I think it should be like this:

 

 

   

Do you mean a separate tag from the  tag, instead of using
, or are you referring to another tag for the
XHTML-ness ;-) of the content? If the former, I'm not sure why we would
want that. If the latter, I disagree that it should be a body tag, since
it needs to be an all-or-nothing tag, not one that applies only to its
body.


I too am confused as to why we would need an additional tag.


Any tag inside  would be rendered as xhtml.  This tag would only
be useful for jsp included files.

Another question: what if  is nested inside
?
   

I think we should probably log a warning. In many cases, the resulting
output will work, but we need to flag that there's a potential problem.

--
Martin Cooper


David


If the outermost document is meant to enforce XHTML, how can an included 
piece *not* conform to XHTML and the entire document still be XHTML?  I 
... feel like we're attempting to over-design - but maybe I'm just 
showing my own ignorance (which is something I don't think I'll ever 
learn not to do - I learn way too much from being willing to do it).

--
Eddie Bush




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

cvs commit: jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold BaseForm.java

[husted]

husted  2002/11/13 11:16:41

  Modified:contrib/scaffold/src/java/org/apache/struts/scaffold
BaseForm.java
  Log:
  + BaseForm: Add convenience methods for testing for required fields
  and if a field representing a value is zero or blank.
  
  Revision  ChangesPath
  1.10  +54 -2 
jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java
  
  Index: BaseForm.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- BaseForm.java 11 Nov 2002 21:25:53 -  1.9
  +++ BaseForm.java 13 Nov 2002 19:16:41 -  1.10
  @@ -20,6 +20,8 @@
   import com.wintecinc.struts.action.ValidatorForm; // Struts 1.0.x
   
   import org.apache.commons.scaffold.lang.ChainedException;
  +import org.apache.commons.scaffold.text.ConvertUtils;
  +import org.apache.commons.scaffold.lang.Tokens;
   
   
   /**
  @@ -150,6 +152,38 @@
   // - Public Methods
   
   /**
  + * Convenience method to test for a required field
  + * and setup the error message.
  + */
  +protected void required(
  +ActionErrors errors,
  +String field,
  +String name,
  +String arg) {
  +if ((null==field) || (0==field.length())) {
  +errors.add(name,
  +new ActionError(Tokens.ERRORS_REQUIRED,arg));
  +}
  +}
  +
  +
  +/**
  + * Convenience method to test for a required array
  + * and setup the error message.
  + */
  +protected void required(
  +ActionErrors errors,
  +String[] field,
  +String name,
  +String arg) {
  +if ((null==field) || (0==field.length)) {
  +errors.add(name,
  +new ActionError(Tokens.ERRORS_REQUIRED,arg));
  +}
  +}
  +
  +
  +/**
* If bean is set to mutable, calls resetSessionLocale
* and setRemoteAddr.
*
  @@ -254,8 +288,26 @@
*
* @param s The sting to check
*/
  +protected boolean blank(String s) {
  +return ConvertUtils.blank(s);
  +}
  +
  +
  +/**
  + * Convenience method to check for a null, empty, or "0" String.
  + *
  + * @param s The sting to check
  + */
  +protected boolean blankValue(String s) {
  +return ConvertUtils.blankValue(s);
  +}
  +
  +
  +/**
  + * @deprecated Use blank instead.
  + */
   protected boolean isBlank(String s) {
  -return ((s==null) || (EMPTY.equals(s)));
  +return blank(s);
   }
   
   
  
  
  

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

RE: [VOTE] How to implement XHMTL support

[Martin Cooper]

On Wed, 13 Nov 2002, David Graham wrote:

> What would  do?

This would be the way Craig was seeking for an included page to tell its
own Struts tags whether to render XHTML or plain HTML. It would set a
*page* context attribute, which the subsequent tags on that page would
check.

As a corollary, the  tag should set the key in
*page* scope rather than request scope, so that each page has to make its
own decision.

>
> If we're going to use a tag I think it should be like this:
> 
>   
>  
>   
> 

Do you mean a separate tag from the  tag, instead of using
, or are you referring to another tag for the
XHTML-ness ;-) of the content? If the former, I'm not sure why we would
want that. If the latter, I disagree that it should be a body tag, since
it needs to be an all-or-nothing tag, not one that applies only to its
body.

>
> Any tag inside  would be rendered as xhtml.  This tag would only
> be useful for jsp included files.
>
> Another question: what if  is nested inside
> ?

I think we should probably log a warning. In many cases, the resulting
output will work, but we need to flag that there's a potential problem.

--
Martin Cooper


>
> David
>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: RE: [VOTE] How to implement XHMTL support
> >Date: Wed, 13 Nov 2002 10:29:21 -0800 (PST)
> >
> >
> >
> >On Wed, 13 Nov 2002, David Graham wrote:
> >
> > > What if we just forgot about the  tag altogether?  If an
> > > included jsp wants to use xhtml they can set the Globals.XHTML_KEY
> >request
> > > parameter to true.
> >
> >How would you propose to do that without using scriptlets, and without
> >"knowing" the value of the key?
> >
> >I think perhaps a  tag is the most straightforward
> >solution.
> >
> >--
> >Martin Cooper
> >
> >
> > >
> > > Keep in mind that the currently implemented solution works for people
> >using
> > >  in a jsp and for people using tiles where they can have a
> > > layout.jsp like this:
> > >
> > > 
> > >
> > > 
> > >
> > > What's left is how to accomodate people using jsp includes.  What do you
> > > think?
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: "Karr, David" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >Subject: RE: [VOTE] How to implement XHMTL support
> > > >Date: Wed, 13 Nov 2002 10:06:56 -0800
> > > >
> > > > > -Original Message-
> > > > > From: David Graham [mailto:dgraham1980@;hotmail.com]
> > > > >
> > > > > What if we did this:
> > > > > 1.  Store a boolean in the request under Globals.XHTML_KEY
> > > > > 2.   would set the boolean to true
> > > > > 3.   (new tag) would set the boolean to true
> > > > > 4.  People could manually set the request attribute if they
> > > > > choose and
> > > > > realize potential problems.
> > > > >
> > > > > This frees you from using , and allows included
> > > > > jsps to set their
> > > > > xhtml status independently of the outer page.
> > > > >
> > > > > Does this accomodate everyone's needs?
> > > >
> > > >Well, I have no "needs" for this, just opinions :) .
> > > >
> > > >Despite the simplicity of "html:xhtml", I think the name should be a
> > > >little more different from "html:html".  I used the example of
> > > >"html:useXhtml" to try to make it clearer that the tag isn't generating
> > > >a HTML tag, and is pretty different from "html:html".
> > > >
> > > >Also (from your other note), if any tags nested (even through
> > > >"jsp:include") in  will NOT use xhtml, then
> > > >that implies that the other tag also needs a "true/false" attribute, as
> > > >opposed to having no attributes (which would imply the tag's presence
> > > >implies "true").
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> > > >
> > > >For additional commands, e-mail:
> > > >
> > >
> > >
> > > _
> > > Tired of spam? Get advanced junk mail protection with MSN 8.
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > > For additional commands, e-mail:
> >
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
>
>
> _
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To u

RE: [VOTE] How to implement XHMTL support

[David Graham]

Forgot this:
5.  Tags nested in  will not be rendered in xhtml 
regardless of any other settings.

Dave






From: "David Graham" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: RE: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 10:41:53 -0700

What if we did this:
1.  Store a boolean in the request under Globals.XHTML_KEY
2.   would set the boolean to true
3.   (new tag) would set the boolean to true
4.  People could manually set the request attribute if they choose and 
realize potential problems.

This frees you from using , and allows included jsps to set 
their xhtml status independently of the outer page.

Does this accomodate everyone's needs?

David





From: "Karr, David" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 09:29:21 -0800

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
>
> The presumption of storing the "outer" xhtml setting
> (independent of *how*
> you do so) is to let the included page automatically adapt to
> the outer
> page's choice - presumably, that lets you use the same
> included page in an
> XHTML and non-XHTML environment with no changes.
>
> But, in reality, that's only true if 100% of the content of
> the included
> page is struts-html tags -- if the developer has any static
> HTML elements,
> for example, they *must* have selected one style or the
> other, and that
> style won't get affected.  You're going to end up with a mishmash.

This is my primary objection to passing the xhtml flag "through" the
jsp:include unconditionally.  The included page needs to have control
over this.

> Maybe what we really need is a way for the included page to
> tell its own
> Struts tags whether or not to be XHTML formatted or not.  Perhaps a
> specialized version of  that was
> searched for the
> same way that the standard version is, but does *not* actually emit an
>  element?

I don't think it would be a "variation" of the "html:html" element, it
would have to be a separate tag, whose only purpose (AFAICS) is to set
this flag.

Would anyone have a reason to specify that the page should NOT use
xhtml?  I could envision a "html:useXhtml" tag (bleah), but should it
have an attribute that specifies a "true" or "false" value, or can it be
attribute-less?

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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

RE: [VOTE] How to implement XHMTL support

[David Graham]

What if we did this:
1.  Store a boolean in the request under Globals.XHTML_KEY
2.   would set the boolean to true
3.   (new tag) would set the boolean to true
4.  People could manually set the request attribute if they choose and 
realize potential problems.

This frees you from using , and allows included jsps to set their 
xhtml status independently of the outer page.

Does this accomodate everyone's needs?

David





From: "Karr, David" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: RE: [VOTE] How to implement XHMTL support
Date: Wed, 13 Nov 2002 09:29:21 -0800

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
>
> The presumption of storing the "outer" xhtml setting
> (independent of *how*
> you do so) is to let the included page automatically adapt to
> the outer
> page's choice - presumably, that lets you use the same
> included page in an
> XHTML and non-XHTML environment with no changes.
>
> But, in reality, that's only true if 100% of the content of
> the included
> page is struts-html tags -- if the developer has any static
> HTML elements,
> for example, they *must* have selected one style or the
> other, and that
> style won't get affected.  You're going to end up with a mishmash.

This is my primary objection to passing the xhtml flag "through" the
jsp:include unconditionally.  The included page needs to have control
over this.

> Maybe what we really need is a way for the included page to
> tell its own
> Struts tags whether or not to be XHTML formatted or not.  Perhaps a
> specialized version of  that was
> searched for the
> same way that the standard version is, but does *not* actually emit an
>  element?

I don't think it would be a "variation" of the "html:html" element, it
would have to be a separate tag, whose only purpose (AFAICS) is to set
this flag.

Would anyone have a reason to specify that the page should NOT use
xhtml?  I could envision a "html:useXhtml" tag (bleah), but should it
have an attribute that specifies a "true" or "false" value, or can it be
attribute-less?

--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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

RE: [VOTE] How to implement XHMTL support

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> 
> The presumption of storing the "outer" xhtml setting 
> (independent of *how*
> you do so) is to let the included page automatically adapt to 
> the outer
> page's choice - presumably, that lets you use the same 
> included page in an
> XHTML and non-XHTML environment with no changes.
> 
> But, in reality, that's only true if 100% of the content of 
> the included
> page is struts-html tags -- if the developer has any static 
> HTML elements,
> for example, they *must* have selected one style or the 
> other, and that
> style won't get affected.  You're going to end up with a mishmash.

This is my primary objection to passing the xhtml flag "through" the
jsp:include unconditionally.  The included page needs to have control
over this.

> Maybe what we really need is a way for the included page to 
> tell its own
> Struts tags whether or not to be XHTML formatted or not.  Perhaps a
> specialized version of  that was 
> searched for the
> same way that the standard version is, but does *not* actually emit an
>  element?

I don't think it would be a "variation" of the "html:html" element, it
would have to be a separate tag, whose only purpose (AFAICS) is to set
this flag.

Would anyone have a reason to specify that the page should NOT use
xhtml?  I could envision a "html:useXhtml" tag (bleah), but should it
have an attribute that specifies a "true" or "false" value, or can it be
attribute-less?

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

Re: [VOTE] How to implement XHMTL support

[Craig R. McClanahan]

On Wed, 13 Nov 2002, David Graham wrote:

> Date: Wed, 13 Nov 2002 07:50:35 -0700
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] How to implement XHMTL support
>
> I'm still unclear on the direction we should take here.  I'd like to hear
> from other committers :-).
>

I haven't voted on this yet -- but it's primarily because I don't really
believe in the  use case being handled like this.

The presumption of storing the "outer" xhtml setting (independent of *how*
you do so) is to let the included page automatically adapt to the outer
page's choice - presumably, that lets you use the same included page in an
XHTML and non-XHTML environment with no changes.

But, in reality, that's only true if 100% of the content of the included
page is struts-html tags -- if the developer has any static HTML elements,
for example, they *must* have selected one style or the other, and that
style won't get affected.  You're going to end up with a mishmash.

Maybe what we really need is a way for the included page to tell its own
Struts tags whether or not to be XHTML formatted or not.  Perhaps a
specialized version of  that was searched for the
same way that the standard version is, but does *not* actually emit an
 element?

> Thanks,
> Dave

Craig


>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: Re: [VOTE] How to implement XHMTL support
> >Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST)
> >
> >We need to ensure that HTML taglib tags in included JSP pages also heed
> >the xhtml attribute. That isn't the case with what's there now, because
> >findAncestorWithClass() will fail for the tags in the included pages.
> >
> >Note that this is why the form tag stores itself in a request attribute.
> >Originally, it also used findAncestorWithClass(), but it was changed to
> >allow forms to span pages.
> >
> >So I see two ways of handling this:
> >
> >A) Have the  tag store itself in a request attribute, and
> >change BaseHandlerTag.isXhtml() to grab the tag from there before calling
> >getXhtml().
> >
> >B) Have the  tag store the value of its 'xhtml' attribute as a
> >request attribute, and use that in BaseHandlerTag.isXhtml().
> >
> >Of these, I prefer the first approach because it makes it harder for
> >people to futz (technical term :) with the value in their pages.
> >
> >--
> >Martin Cooper
> >
> >
> >On Tue, 12 Nov 2002, David Graham wrote:
> >
> > > I've updated that html taglib tags to output xhtml when they are nested
> >in a
> > >  tag.  This was very simple to do and resulted
> >in
> > > minor code changes.  Users have suggested this approach:
> > >
> > > 1.  Add Globals.XHTML_KEY which is a boolean request scoped attribute
> > > 2.  html tags check for that request attribute being true and output
> > > accordingly.
> > > 3.  The html:html tag sets this request attribute when it's xhtml
> >attribute
> > > is true.
> > >
> > > The second approach allows the tags to output xhtml without relying on
> >the
> > >  tag.  This allows people to construct pages with jsp
> >includes.
> > > The first approach is logically clearer (to me) and you can use tiles to
> > > modularly construct the pages like includes.  Approach 2 may be
> >confusing
> > > because you would have to remember all the places you may have set that
> > > request attribute.
> > >
> > > So, do we go with 1, 2 or both?
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > > _
> > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > > For additional commands, e-mail:
> >
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
>
>
> _
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: [VOTE] How to implement XHMTL support

[Eddie Bush]

Don't bother drawing a ballot up - these guys don't use it! 
They're all like thinking outside the box and adding options to it, 
dude!  ... and there's that one fellow who is always saying "put your 
code where your mouth is - we only vote on code" - while standing there 
with a wild, Clint Eastwood look on his face!  (Go ahead punk - make my 
release-candidate!)  In any case, most people will tell you to ask for 
forgiveness instead of permission.

I would follow Martin's suggest course of action, plan A.  This way, you 
wind up having access to the tag, which is the Information Expert here. 
I don't agree with Martin's suggestion that this is a more robust way 
to handle things - I just think it's sensless to create things you don't 
need to.  It's irrelevant whether you put a Boolean or the tag-handler 
out there with respect to the mucking of variables - the tag-handler is 
a java-bean, right?  Thus, it could easily be updated at any stage too 
(ie futzed with).  I do think it would be more efficient (albeit ever-so 
slightly) to just use the tag, since there is no additional creation of 
a Boolean object to stuff into the request.

In either case, yes, you're going to want to add some key to Globals - 
the name of it I wouldn't hazard a guess at.  What you have sounds ok, 
but it's really representing the tag now, so perhaps it should reflect 
that in it's name?  (ok, fine, I will hazard a pseudo-guess at it! ;-)

David Graham wrote:

I'm still unclear on the direction we should take here.  I'd like to 
hear from other committers :-).

Thanks,
Dave 

--
Eddie Bush




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

Re: ChainAction class

[Karl Baum]

The ChainAction was intended to be another option for users in defining
their actions in the struts-config.  User's are not forced to chain actions
together in each ActionMapping.  For this reason in lieu of a Custom Reqeust
Processor, we decided to use the existing Struts Action architecture to
chain Actions together.  We were able to implement this COR pattern without
making any changes to the existing Struts Architecture.

The chains of Actions could be maintained in additional config xml file to
be used in combination with the existing struts configuration.  Obviously
this configuration file is not manditory, as users can choose not to define
ChainAction's in their struts-config.


- Original Message -
From: "Daniel Honig" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>; "Karl Baum"
<[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 7:37 PM
Subject: RE: ChainAction class


> I would just like to instigate some trouble along with this question
> since I am a big fan of the "Chain Of Repsonsibility" pattern
> and agree that it can do a nice job of creating atomic
> and reusable code structures.
>
> I would also like to say that I think it could be confusing
> to have a chain action.  The example provided for invoking
> actions based on Locale is handled by implementing someone's
> own custom RequestProcessor.  Fan of the COR pattern I may be
> but implementing a custom RequestProcessor seems cleaner.
>
> One problem if you implement COR is how do you assemble and execute
chains?
> Where do you store this info?
>
> Servlet Filters offer another chance to implement COR.
>
> Perhaps I'm hallucinating again,  but has craig talked about COR and Java
> Server Faces?
>
> I think its' great if the contribution doesn't hurt anything else and
> pending
> the design is good.  But I think most cases for use in a COR environment
> can be handled other ways.  COR is a nice way to redirect output streams
> for several transformations of the output stream.  Say you had one action
> that read data from a database and output xml.  You could continue to add
> chain processors until it outputs a PDF file.
>
>
> -Daniel
>
> -Original Message-
> From: Karl Baum [mailto:kbaum@;Tallan.com]
> Sent: Tuesday, November 12, 2002 4:19 PM
> To: Struts Developers Lis
> Subject: ChainAction class
>
>
> Over the past year and a half, I have developed using the Struts platform.
>
> During this time, my colleagues and I created an Action class which allows
> other actions to be chained together.  This design resembled the Chain of
> Responsibility pattern.   The ChainAction class was well received by the
> many other developers on our project.  Most importantly it helped keep our
> Action components simple and modular and promoted reuse in our code.  In
> addition, the ChainAction class allowed for different Actions to be
executed
> based on Locale.
>
> I have been benefiting from the Struts Model View Controller framework for
> some time and would like to contribute the ChainAction class to the
> framework.  The addition of the ChainAction class would require no change
> to the existing Struts code base and would only offer Struts users an
> additional Action class implementation.
>
> I would like to gauge the interest other Struts developers have in this
> idea.  Thanks.
>
> Karl
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


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

RE: Trying the developer list...

[Michael Delamere]

Hi,

thanks for your reply.  I just wanted to add that I haven’t actually
tried adding the property attribute to the bean:write tag yet, so the
problem still remains...

Regards,

Michael


-Original Message-
From: Hal Deadman [mailto:hal.deadman@;Tallan.com] 
Sent: Mittwoch, 13. November 2002 17:40
To: 'Struts Developers List'
Subject: RE: Trying the developer list...

No you can't do that with bean:write. If you want a specific property,
specify the property in the html:messages tag and only messages with
that
key will be itereated over.

> -Original Message-
> From: Michael Delamere [mailto:home@;michael-delamere.de]
> Sent: Wednesday, November 13, 2002 5:41 AM
> To: [EMAIL PROTECTED]
> Subject: Trying the developer list...
>
>
> Hi,
>
> I´ve tried answering the following question via the user-list
> twice and
> I have not yet received the solution that I am looking for.  I´ve been
> on this for quite some time now and cannot get it to work!
>
> Basically, I want to pass ActionMessages to my JSP using the
> methods and
> classes provided by struts.
>
> Here is the code in my Action:
>
> ActionMessages messages = new ActionMessages();
> ActionMessage newMessage = new
> ActionMessage("from.my.resourcebundle.text");
> messages.add("key.I.pass.to.jsp", newMessage);
> saveMessages(request, messages);
>
> // I also tried saving it directly
> //request.setAttribute(Action.MESSAGE_KEY, messages);
>
>
> Now in my JSP I would have the following:
>
> 
>  
> 
>
> Whenever I put this code into my JSP however, I get the error:
>
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:386)
> at
> org.apache.jasper.runtime.PageContextImpl.setAttribute(PageCon
> textImpl.j
> ava:229) at
> org.apache.struts.taglib.html.MessagesTag.doStartTag(MessagesT
> ag.java:25
> 3)
>
> Any help on this matter would be very much appreciated
> because I really
> need to get this working!
>
> Regards,
>
>
> Michael
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: [VOTE] How to implement XHMTL support

[Hal Deadman]

I agree with Martin that you can't ignore people using jsp:include. I prefer
his option B because then it allows someone to use the xhtml support in the
other tags without forcing them to use . They would have to set
the attribute themselves and assume the risks that go along with making
assumptions about how the tag is working.

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Wednesday, November 13, 2002 9:51 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] How to implement XHMTL support
>
>
> I'm still unclear on the direction we should take here.  I'd
> like to hear
> from other committers :-).
>
> Thanks,
> Dave
>
>
>
>
>
>
> >From: Martin Cooper <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: Re: [VOTE] How to implement XHMTL support
> >Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST)
> >
> >We need to ensure that HTML taglib tags in included JSP
> pages also heed
> >the xhtml attribute. That isn't the case with what's there
> now, because
> >findAncestorWithClass() will fail for the tags in the included pages.
> >
> >Note that this is why the form tag stores itself in a
> request attribute.
> >Originally, it also used findAncestorWithClass(), but it was
> changed to
> >allow forms to span pages.
> >
> >So I see two ways of handling this:
> >
> >A) Have the  tag store itself in a request attribute, and
> >change BaseHandlerTag.isXhtml() to grab the tag from there
> before calling
> >getXhtml().
> >
> >B) Have the  tag store the value of its 'xhtml'
> attribute as a
> >request attribute, and use that in BaseHandlerTag.isXhtml().
> >
> >Of these, I prefer the first approach because it makes it harder for
> >people to futz (technical term :) with the value in their pages.
> >
> >--
> >Martin Cooper
> >
> >
> >On Tue, 12 Nov 2002, David Graham wrote:
> >
> > > I've updated that html taglib tags to output xhtml when
> they are nested
> >in a
> > >  tag.  This was very simple to do
> and resulted
> >in
> > > minor code changes.  Users have suggested this approach:
> > >
> > > 1.  Add Globals.XHTML_KEY which is a boolean request
> scoped attribute
> > > 2.  html tags check for that request attribute being true
> and output
> > > accordingly.
> > > 3.  The html:html tag sets this request attribute when it's xhtml
> >attribute
> > > is true.
> > >
> > > The second approach allows the tags to output xhtml
> without relying on
> >the
> > >  tag.  This allows people to construct pages with jsp
> >includes.
> > > The first approach is logically clearer (to me) and you
> can use tiles to
> > > modularly construct the pages like includes.  Approach 2 may be
> >confusing
> > > because you would have to remember all the places you may
> have set that
> > > request attribute.
> > >
> > > So, do we go with 1, 2 or both?
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > > _
> > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > > For additional commands, e-mail:
> >
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> >
> >For additional commands, e-mail:
> >
>
>
> _
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

RE: Trying the developer list...

[Hal Deadman]

No you can't do that with bean:write. If you want a specific property,
specify the property in the html:messages tag and only messages with that
key will be itereated over.

> -Original Message-
> From: Michael Delamere [mailto:home@;michael-delamere.de]
> Sent: Wednesday, November 13, 2002 5:41 AM
> To: [EMAIL PROTECTED]
> Subject: Trying the developer list...
>
>
> Hi,
>
> I´ve tried answering the following question via the user-list
> twice and
> I have not yet received the solution that I am looking for.  I´ve been
> on this for quite some time now and cannot get it to work!
>
> Basically, I want to pass ActionMessages to my JSP using the
> methods and
> classes provided by struts.
>
> Here is the code in my Action:
>
> ActionMessages messages = new ActionMessages();
> ActionMessage newMessage = new
> ActionMessage("from.my.resourcebundle.text");
> messages.add("key.I.pass.to.jsp", newMessage);
> saveMessages(request, messages);
>
> // I also tried saving it directly
> //request.setAttribute(Action.MESSAGE_KEY, messages);
>
>
> Now in my JSP I would have the following:
>
> 
>  
> 
>
> Whenever I put this code into my JSP however, I get the error:
>
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:386)
> at
> org.apache.jasper.runtime.PageContextImpl.setAttribute(PageCon
> textImpl.j
> ava:229) at
> org.apache.struts.taglib.html.MessagesTag.doStartTag(MessagesT
> ag.java:25
> 3)
>
> Any help on this matter would be very much appreciated
> because I really
> need to get this working!
>
> Regards,
>
>
> Michael
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


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

DO NOT REPLY [Bug 14506] - unable to load validator xml's dtds from local source

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14506

unable to load validator xml's dtds from local source

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-13 16:36 ---
This has been fixed in the Nightly builds.
The validator.dtd at one time was in both
commons-validator --and--struts with only
a minor difference. This difference was
resolved, and now the dtd only exists
in the commons validator.
So get the most recient nightly build
of struts and recompile your application
against this JAR deploying all the new .xml
& .jar files with your application.

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

Re: [VOTE] How to implement XHMTL support

[David Graham]

I'm still unclear on the direction we should take here.  I'd like to hear 
from other committers :-).

Thanks,
Dave






From: Martin Cooper <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: [VOTE] How to implement XHMTL support
Date: Tue, 12 Nov 2002 16:57:07 -0800 (PST)

We need to ensure that HTML taglib tags in included JSP pages also heed
the xhtml attribute. That isn't the case with what's there now, because
findAncestorWithClass() will fail for the tags in the included pages.

Note that this is why the form tag stores itself in a request attribute.
Originally, it also used findAncestorWithClass(), but it was changed to
allow forms to span pages.

So I see two ways of handling this:

A) Have the  tag store itself in a request attribute, and
change BaseHandlerTag.isXhtml() to grab the tag from there before calling
getXhtml().

B) Have the  tag store the value of its 'xhtml' attribute as a
request attribute, and use that in BaseHandlerTag.isXhtml().

Of these, I prefer the first approach because it makes it harder for
people to futz (technical term :) with the value in their pages.

--
Martin Cooper


On Tue, 12 Nov 2002, David Graham wrote:

> I've updated that html taglib tags to output xhtml when they are nested 
in a
>  tag.  This was very simple to do and resulted 
in
> minor code changes.  Users have suggested this approach:
>
> 1.  Add Globals.XHTML_KEY which is a boolean request scoped attribute
> 2.  html tags check for that request attribute being true and output
> accordingly.
> 3.  The html:html tag sets this request attribute when it's xhtml 
attribute
> is true.
>
> The second approach allows the tags to output xhtml without relying on 
the
>  tag.  This allows people to construct pages with jsp 
includes.
> The first approach is logically clearer (to me) and you can use tiles to
> modularly construct the pages like includes.  Approach 2 may be 
confusing
> because you would have to remember all the places you may have set that
> request attribute.
>
> So, do we go with 1, 2 or both?
>
> David
>
>
>
>
>
> _
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> --
> To unsubscribe, e-mail:   

> For additional commands, e-mail: 

>
>


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


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

DO NOT REPLY [Bug 14506] New: - unable to load validator xml's dtds from local source

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=14506

unable to load validator xml's dtds from local source

   Summary: unable to load validator xml's dtds from local source
   Product: Struts
   Version: 1.1 Beta 2
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Initialization of validator on computer which has no access to internet failed
because it was unable to download dtds (validation_1_1.dtd etc..). 
Initialization of struts itself went ok, although its configuration files 
(struts-config.xml) should also be validated using dtds from remote source (or
am I wrong?). I'm not sure if this is a bug at all, but I find this behavior
at least strange.

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

Re: OT - XFORMS Tag:

[David Graham]

This will probably be handled by JavaServer Faces.

David







From: "V. Cekvenich" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: OT - XFORMS Tag:
Date: Wed, 13 Nov 2002 07:58:55 -0500

One day form processing will be done like this:

1. XForms 1.0 has become a W3C Candidate Recommendation.


2. J2EE server has pre-view:

*  http://help.silverstream.com/help/XFormsTutorial/ *

3. Here is a plug in for IE:
http://www.FormsPlayer.com

just fyi, anyone planing long term direction.

.V




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail


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

RE: OT - XFORMS Tag:

[James Higginbotham]

Yeah, I haven't had time to read the spec since May '01.. I wanted to
use this to construct faces on web services, but it was so tied to
HTTP.. I needed something that would work within Swing as well. I hope
this has changed since then.. It would be handy to have this support
from IE/Mozilla to Flash and Swing.. 

James

> -Original Message-
> From: V. Cekvenich [mailto:vic@;baseBeans.com] 
> Sent: Wednesday, November 13, 2002 6:59 AM
> To: [EMAIL PROTECTED]
> Subject: OT - XFORMS Tag:
> 
> 
> One day form processing will be done like this:
> 
> 1. XForms 1.0 has become a W3C Candidate Recommendation.
> 
> 
> 2. J2EE server has pre-view:
> 
> *  http://help.silverstream.com/help/XFormsTutorial/ *
> 
> 3. Here is a plug in for IE:
> http://www.FormsPlayer.com
> 
> just fyi, anyone planing long term direction.
> 
> .V
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

OT - XFORMS Tag:

[V. Cekvenich]

One day form processing will be done like this:

1. XForms 1.0 has become a W3C Candidate Recommendation.


2. J2EE server has pre-view:

*  http://help.silverstream.com/help/XFormsTutorial/ *

3. Here is a plug in for IE:
http://www.FormsPlayer.com

just fyi, anyone planing long term direction.

.V




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

Trying the developer list...

[Michael Delamere]

Hi,

I´ve tried answering the following question via the user-list twice and
I have not yet received the solution that I am looking for.  I´ve been
on this for quite some time now and cannot get it to work!

Basically, I want to pass ActionMessages to my JSP using the methods and
classes provided by struts.

Here is the code in my Action:

ActionMessages messages = new ActionMessages();
ActionMessage newMessage = new
ActionMessage("from.my.resourcebundle.text");
messages.add("key.I.pass.to.jsp", newMessage);
saveMessages(request, messages);

// I also tried saving it directly
//request.setAttribute(Action.MESSAGE_KEY, messages);


Now in my JSP I would have the following:


 


Whenever I put this code into my JSP however, I get the error:

java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:386)
at
org.apache.jasper.runtime.PageContextImpl.setAttribute(PageContextImpl.j
ava:229) at
org.apache.struts.taglib.html.MessagesTag.doStartTag(MessagesTag.java:25
3)

Any help on this matter would be very much appreciated because I really
need to get this working!

Regards,


Michael


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