DO NOT REPLY [Bug 31481] New: - [struts-tiles]: ControllerSupport doesn't support Struts 1.1 controllers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31481. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31481 [struts-tiles]: ControllerSupport doesn't support Struts 1.1 controllers Summary: [struts-tiles]: ControllerSupport doesn't support Struts 1.1 controllers Product: Struts Version: 1.2.4 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Tiles framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The delegate in ControllerSupport from perform() to execute() ist the wrong direction. Struts 1.1-controllers implement the perform()-method because this method is called by the framework. If have these old controllers with Struts 1.2 running, the execute()-Method of ControllerSupport is called - but this method is empty. But it should delegate to perform(). It doesn't make sense to let perform() delegate to execute() because nobody calls perform in Struts 1.2. Thanks Lars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem related to Struts-tiles
Hi, Such question should be post in the struts-user mailing list :-). Tiles is a framework that build pages by assembling fragment or tiles on the server side. When you request a page made of tiles, the server return the entire page, not a particular tile. If you want only a particular area of your page to be updated, you need to use frames (interpreted on the client side). Tiles and frames can be mixed, but you need to manage the frame yourself. Tiles can't do it for you. Hope this help, Cedric Anant D Agarwal wrote: Hi, I am using tiles in my project .I am using classic layout my tiles-defs.xml which i made have one definition tag like this definition name=site.mainLayout path=/layouts/classicLayout.jsp put name=title value=Tiles Blank Site / put name=header value=/tiles/common/header.jsp / put name=menu value=/tiles/common/menu.jsp / put name=footer value=/tiles/common/footer.jsp / put name=body value=/tiles/body.jsp / /definition now I am extending this definition tag with another definition definition name=site.homeLayout extends=site.mainLayout put name=body value=/tiles/homebody.jsp / /definition Now when in my first definition i have one menu.jsp on clicking on that menu i call extended definition. Now problem it refresh the entire page instead of body page. I want only body content should refresh rest header,footer and menu should remain like this just like when we use frames. kindlly suggest what should i do. regards thanks Anant Regards and thanks, Anant Anant Das Agarwal IBM Global Services India Pvt Ltd X1-7, Block-EP/GP, Sector-V Salt Lake Electronic Complex Kolkata 700091 +91 33 2357 9110 x 3405 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem related to Struts-tiles
Cedric Dumoulin wrote: Greeting Cedric: It has been a long time to see you again on the list. I wonder if you have some time to make tiles work better with faces. Here is what I have tried faces and tiles without struts (so no plug-in): 1) If i load TileServlet as instructed, the log said tile factory has been successully loaded, but somehow the definition factory is not loaded. Hence tiles definitions defined in tiles.xml are not available. This was done with Faces latest RI. 2) I try tiles with myfaces, i got the same issue about definition factory. However, if i define tile definition in a page, it works in myfaces but not in RI. I hope you or someone else can give a definitive instruction. BaTien DBGROUPS Hi, Such question should be post in the struts-user mailing list :-). Tiles is a framework that build pages by assembling fragment or tiles on the server side. When you request a page made of tiles, the server return the entire page, not a particular tile. If you want only a particular area of your page to be updated, you need to use frames (interpreted on the client side). Tiles and frames can be mixed, but you need to manage the frame yourself. Tiles can't do it for you. Hope this help, Cedric Anant D Agarwal wrote: Hi, I am using tiles in my project .I am using classic layout my tiles-defs.xml which i made have one definition tag like this definition name=site.mainLayout path=/layouts/classicLayout.jsp put name=title value=Tiles Blank Site / put name=header value=/tiles/common/header.jsp / put name=menu value=/tiles/common/menu.jsp / put name=footer value=/tiles/common/footer.jsp / put name=body value=/tiles/body.jsp / /definition now I am extending this definition tag with another definition definition name=site.homeLayout extends=site.mainLayout put name=body value=/tiles/homebody.jsp / /definition Now when in my first definition i have one menu.jsp on clicking on that menu i call extended definition. Now problem it refresh the entire page instead of body page. I want only body content should refresh rest header,footer and menu should remain like this just like when we use frames. kindlly suggest what should i do. regards thanks Anant Regards and thanks, Anant Anant Das Agarwal IBM Global Services India Pvt Ltd X1-7, Block-EP/GP, Sector-V Salt Lake Electronic Complex Kolkata 700091 +91 33 2357 9110 x 3405 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsCatalog
Date: 2004-09-30T14:43:09 Editor: NiallPemberton [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsCatalog URL: http://wiki.apache.org/struts/StrutsCatalog no comment Change Log: -- @@ -19,3 +19,4 @@ * StrutsCatalogHtmlRewrite * StrutsCatalogSegmentApplications * StrutsCatalogVariableScreenFields + * StrutsCatalogLazyList - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] New: StrutsCatalogLazyList
Date: 2004-09-30T15:57:57
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogLazyList
URL: http://wiki.apache.org/struts/StrutsCatalogLazyList
no comment
New Page:
There are two frequent issues the confront people when dealing with populating a
collection of beans in an ActionForm.
* How can I generate the appropriate html using the struts taglibs?
* I have a request scoped ActionForm and am getting an index out of range error
when I submit the form - what do I do?
The ''Indexed Properies'' section below deals with generating the html and the ''Lazy
List'' section shows possible solutions for avoiding the index out of range error.
== Indexed Properties ==
Struts html tags have an ''indexed'' attribute which will generate the appropriate
html to populate a collection of beans when the form is submitted.
For example the following jsp...
{{{
html:iterate name=skillsForm property=skills id=skills
html:text name=skills property=skillId indexed=true/
/html:iterate
}}}
...will generate the following html
{{{
input type=text name=skills[0].skillId value=.../
input type=text name=skills[1].skillId value=.../
input type=text name=skills[n].skillId value=.../
}}}
When the form is submitted BeanUtils will first call the getSkills(index) method to
retrieve the indexed bean followed by setSkillId(..) on the retrieved bean.
== Lazy List Behaviour ==
A common problem with indexed properties, is that people then get index out of range
errors with ActionForms that are in Request scope. The indexed property (List or
Array) needs to be able to automatically ''grow'' during the ActionForm population
process. The key to achieving this is in the get(index) method.
The following sections show three examples of how to achieve lazy list processing.
=== Hand Cranking lazy List in the ActionForm ===
{{{
public class SkillActionForm extends ActionForm {
protected List skills = new ArrayList();
public List getSkills() {
return skills;
}
public void setSkills(List skills) {
this.skills = skills;
}
public SkillBean getSkills(int index) {
// automatically grow List size
while (index = skills.size()) {
skills.add(new SkillBean());
}
return skills.get(index);
}
}
}}}
=== Using Commons Collections for lazy Lists ===
Commons collections have a lazy list decorator which automatically grows the list when
the get(int) method is called. In the example below the ActionForm implements the
Factory interface, providing the create() method to populate an entry in the List.
{{{
import org.apache.commons.collections.Factory;
import org.apache.commons.collections.list.LazyList;
public class SkillActionForm extends ActionForm, implements Factory {
protected List skills = LazyList.decorate(new ArrayList(), this);
public List getSkills() {
return skills;
}
public void setSkills(List skills) {
this.skills = skills;
}
public SkillBean getSkills(int index) {
return skills.get(index);
}
// 'Factory' method for LazyList
public Object create() {
return new SkillBean();
}
}
}}}
=== LazyDynaBean / LazyValidatorForm ===
'''N.B.''' Solutions here require '''Struts 1.2.4''' and '''Bean Utils 1.7.0'''
[http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/package-summary.html#dynamic.lazy
LazyDynaBean] in [http://jakarta.apache.org/commons/beanutils/ Commons BeanUtils] has
the ''lazy'' List type processing.
[http://www.niallp.pwp.blueyonder.co.uk/#lazydynabean LazyValidatorForm] is built
using the BeanUtils LazyDynaBean and can be used by simply configuring it through the
struts-config.xml.
{{{
form-beans
form-bean name=skillForm type=org.apache.struts.validator.LazyValidatorForm
form-property name=skills type=java.util.ArrayList/
/form-bean
/form-beans
}}}
In fact using Arrays (rather than Lists) a LazyDynaBean can be used directly, in the
following way:
{{{
form-beans
form-bean name=skillForm type=org.apache.commons.beanutils.LazyDynaBean
form-property name=skills type=myPackage.SkillBean[]/
/form-bean
/form-beans
}}}
Struts 1.2.4 will ''wrap'' the LazyDynaBean in a BeanValidatorForm automatically.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Opening it up for debate...
I came across something yesterday that might be good fodder for a debate... Consider a simple login page. You submit the typical form with a userID and password. Your ActionForm performs a validation to be sure they filled in both fields and returns errors if any validation fails. Simple enough. You do the usual html:errors/ to display the errors. Now... Presumably most of us would now do the AUTHENTICATION from an Action (well, delegated of course), as opposed to doing it from the validate() method (I wouldn't view that as correct myself). Let's say the user is not authenticated (bad password perhaps)... So you forward to a failure forward, but what about displaying an error message to the user? I imagine the typical thought is to put a message in a request attribute and do a bean:write to display it (with ignore=true probably), or maybe more properly set some attribute of the form. So, here's my point... We have in the JSP an html:errors/ tag to display VALIDATION errors, but we also have a bean:write/ to display the AUTHENTICATION errors. Is that optimal? Why can't we do it with one line (or can we? I don't mind learning something new!) My thought is that maybe it would be appropriate to handle BOTH these situations by returning an ActionErrors collection. Ok, fine, we can insert it into request in the Action manually, but that's not a good idea because the attribute name might change down the road. High-coupling and all that jazz. What to do? Well, the first question is, does anyone agree that it makes some sense to handle both situations with ActionErrors, and thereby only have a single line in the JSP to display both types of errors? If not, ignore the rest of this. If you agree with that though, here's my suggestion... What if execute() in the Action returned an Object, and the object either implements an empty ActionForwardResult interface or an ActionErrorsResult interface (I just made those up of course), and that can be determined, the object casted and acted upon either as the usual ActionForward or the same way an ActionErrors is treated from validate() in the form. What does everyone think? Am I making a big deal out of the arguably minor inelegance of two error display lines in the JSP, or is this possibly a real issue to deal with? Even if you don't view it as a problem, might this change result in a bit more flexibility that might be good, or would it be breaking some architectural rules (I'm a bit mixed on that last point frankly). Thanks all! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsCatalogLazyList
Date: 2004-09-30T16:05:00 Editor: NiallPemberton [EMAIL PROTECTED] Wiki: Apache Struts Wiki Page: StrutsCatalogLazyList URL: http://wiki.apache.org/struts/StrutsCatalogLazyList no comment Change Log: -- @@ -4,6 +4,8 @@ * I have a request scoped ActionForm and am getting an index out of range error when I submit the form - what do I do? +More info on indexed properties available in the [http://struts.apache.org/faqs/indexedprops.html FAQs] + The ''Indexed Properies'' section below deals with generating the html and the ''Lazy List'' section shows possible solutions for avoiding the index out of range error. == Indexed Properties == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsCatalogLazyList
Date: 2004-09-30T16:25:00
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogLazyList
URL: http://wiki.apache.org/struts/StrutsCatalogLazyList
no comment
Change Log:
--
@@ -10,7 +10,7 @@
== Indexed Properties ==
-Struts html tags have an ''indexed'' attribute which will generate the appropriate
html to populate a collection of beans when the form is submitted.
+Struts html tags have an ''indexed'' attribute which will generate the appropriate
html to populate a collection of beans when the form is submitted. The ''trick'' is to
name the '''id''' attribute to the same as the indexed property.
For example the following jsp...
@@ -63,7 +63,7 @@
skills.add(new SkillBean());
}
- return skills.get(index);
+ return (SkillBean)skills.get(index);
}
@@ -94,7 +94,7 @@
}
public SkillBean getSkills(int index) {
- return skills.get(index);
+ return (SkillBean)skills.get(index);
}
// 'Factory' method for LazyList
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
First I have to say, that I use container managed security for logon -
rather rolling my own with an Action.
Having said that I don't really see what the issue is - just use the same
error mechanism that the validate() method uses - create an
ActionMessages/ActionErrors object, stick the key to the authentication
error in it, save the errors under the standard key and return to the input
forward.
In Struts 1.1 it would be something like the following in the Action's
execute method...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
ActionErrors errors = new ActionErrors();
errors.add(logon, new ActionError(authenticate.error);
saveErrors(request, errors);
return getInputForward();
}
In Struts 1.2.4 it slightly simpler...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
getErrors(request).add(logon, new
ActionError(authenticate.error);
return getInputForward();
}
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Friday, October 01, 2004 12:01 AM
Subject: Opening it up for debate...
I came across something yesterday that might be good fodder for a
debate...
Consider a simple login page. You submit the typical form with a userID
and password. Your ActionForm performs a validation to be sure they
filled in both fields and returns errors if any validation fails.
Simple enough. You do the usual html:errors/ to display the errors.
Now... Presumably most of us would now do the AUTHENTICATION from an
Action (well, delegated of course), as opposed to doing it from the
validate() method (I wouldn't view that as correct myself). Let's say
the user is not authenticated (bad password perhaps)... So you forward
to a failure forward, but what about displaying an error message to
the user?
I imagine the typical thought is to put a message in a request attribute
and do a bean:write to display it (with ignore=true probably), or
maybe more properly set some attribute of the form.
So, here's my point... We have in the JSP an html:errors/ tag to
display VALIDATION errors, but we also have a bean:write/ to display
the AUTHENTICATION errors. Is that optimal? Why can't we do it with
one line (or can we? I don't mind learning something new!)
My thought is that maybe it would be appropriate to handle BOTH these
situations by returning an ActionErrors collection. Ok, fine, we can
insert it into request in the Action manually, but that's not a good
idea because the attribute name might change down the road.
High-coupling and all that jazz.
What to do? Well, the first question is, does anyone agree that it
makes some sense to handle both situations with ActionErrors, and
thereby only have a single line in the JSP to display both types of
errors? If not, ignore the rest of this.
If you agree with that though, here's my suggestion... What if execute()
in the Action returned an Object, and the object either implements an
empty ActionForwardResult interface or an ActionErrorsResult interface
(I just made those up of course), and that can be determined, the object
casted and acted upon either as the usual ActionForward or the same way
an ActionErrors is treated from validate() in the form.
What does everyone think? Am I making a big deal out of the arguably
minor inelegance of two error display lines in the JSP, or is this
possibly a real issue to deal with? Even if you don't view it as a
problem, might this change result in a bit more flexibility that might
be good, or would it be breaking some architectural rules (I'm a bit
mixed on that last point frankly). Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
Ah, I didn't know about the saveErrors method. That completely
invalidates my entire concern. Thank you! I figured I was either on to
something or was about to learn something, and I kinda figured it would
be the later :)
Niall Pemberton wrote:
First I have to say, that I use container managed security for logon -
rather rolling my own with an Action.
Having said that I don't really see what the issue is - just use the same
error mechanism that the validate() method uses - create an
ActionMessages/ActionErrors object, stick the key to the authentication
error in it, save the errors under the standard key and return to the input
forward.
In Struts 1.1 it would be something like the following in the Action's
execute method...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
ActionErrors errors = new ActionErrors();
errors.add(logon, new ActionError(authenticate.error);
saveErrors(request, errors);
return getInputForward();
}
In Struts 1.2.4 it slightly simpler...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
getErrors(request).add(logon, new
ActionError(authenticate.error);
return getInputForward();
}
Niall
- Original Message -
From: Frank W. Zammetti [EMAIL PROTECTED]
To: Struts Developer [EMAIL PROTECTED]
Sent: Friday, October 01, 2004 12:01 AM
Subject: Opening it up for debate...
I came across something yesterday that might be good fodder for a
debate...
Consider a simple login page. You submit the typical form with a userID
and password. Your ActionForm performs a validation to be sure they
filled in both fields and returns errors if any validation fails.
Simple enough. You do the usual html:errors/ to display the errors.
Now... Presumably most of us would now do the AUTHENTICATION from an
Action (well, delegated of course), as opposed to doing it from the
validate() method (I wouldn't view that as correct myself). Let's say
the user is not authenticated (bad password perhaps)... So you forward
to a failure forward, but what about displaying an error message to
the user?
I imagine the typical thought is to put a message in a request attribute
and do a bean:write to display it (with ignore=true probably), or
maybe more properly set some attribute of the form.
So, here's my point... We have in the JSP an html:errors/ tag to
display VALIDATION errors, but we also have a bean:write/ to display
the AUTHENTICATION errors. Is that optimal? Why can't we do it with
one line (or can we? I don't mind learning something new!)
My thought is that maybe it would be appropriate to handle BOTH these
situations by returning an ActionErrors collection. Ok, fine, we can
insert it into request in the Action manually, but that's not a good
idea because the attribute name might change down the road.
High-coupling and all that jazz.
What to do? Well, the first question is, does anyone agree that it
makes some sense to handle both situations with ActionErrors, and
thereby only have a single line in the JSP to display both types of
errors? If not, ignore the rest of this.
If you agree with that though, here's my suggestion... What if execute()
in the Action returned an Object, and the object either implements an
empty ActionForwardResult interface or an ActionErrorsResult interface
(I just made those up of course), and that can be determined, the object
casted and acted upon either as the usual ActionForward or the same way
an ActionErrors is treated from validate() in the form.
What does everyone think? Am I making a big deal out of the arguably
minor inelegance of two error display lines in the JSP, or is this
possibly a real issue to deal with? Even if you don't view it as a
problem, might this change result in a bit more flexibility that might
be good, or would it be breaking some architectural rules (I'm a bit
mixed on that last point frankly). Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ah, I didn't know about the saveErrors method. That completely invalidates my entire concern. Thank you! I figured I was either on to something or was about to learn something, and I kinda figured it would be the later :) BTW, this is also the approach that the standard Struts example application (struts-example) uses to deal with this scenario. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
At 7:01 PM -0400 9/30/04, Frank W. Zammetti wrote: I came across something yesterday that might be good fodder for a debate... Another approach which I have used is to consider an authorization failure a business exception and throw an UnauthorizedUserException which can then be mapped using Struts declarative exception handling to look up the appropriate message (based on the exception handler config's key property) and deliver a usable message to an Error JSP. But now that you know about saveErrors (and don't forget saveMessages), you probably don't need yet another solution! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
I actually have to plead ignorance on that... In all honesty, I haven't looked over the sample apps as much as I probably should... I'm one of those people that prefers to just jump in, start coding something and figure it out as I go. Plus, I don't generally like looking at other people's code, it usually winds up taking more time and effort to figure it out than just working out the solution myself. Here however is a situation where looking at the samples would have been very beneficial, and saved a little bit of traffic on the list. Simply put, my bad :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Craig McClanahan wrote: On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ah, I didn't know about the saveErrors method. That completely invalidates my entire concern. Thank you! I figured I was either on to something or was about to learn something, and I kinda figured it would be the later :) BTW, this is also the approach that the standard Struts example application (struts-example) uses to deal with this scenario. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31501] New: - html:form focus generates non-XHTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31501. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31501 html:form focus generates non-XHTML Summary: html:form focus generates non-XHTML Product: Struts Version: 1.2.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The generated javascript when using html:form focus=username ...etc is not encased in !-- XML comment tags -- Because this particular javascript contains the document is no longer XHTML compliant. This is the case even when you have html:html xhtml=true and html:xhtml/ in the JSP. Note, this is actually happening inStruts 1.2.2 but wasnt an option on the bug reporting page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
