Thanks for the information. I think I will stick with Struts 1.1 for now,
then. We have the opportunity at some point on a later project to perhaps do
a Struts 2 migration. I think it's probably wiser to implement the
Javascript way of handling this for now and save the Struts migration
(sometimes you only get one shot at these every X amount of years) for
giving Struts 2 a look if it fits our needs.
Preston
-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED]
Sent: Friday, April 06, 2007 11:01 AM
To: Struts Users Mailing List
Subject: Re: Does struts 1.2.x or 1.3.x support the attribute "autocomplete"
f or forms?
On 4/6/07, Crawford, Preston <[EMAIL PROTECTED]> wrote:
> I'm sure many of you know about this. The originally IE specific
> attribute "autocomplete", that when set to "off" would prevent the
> browser from saving the data in the form for autocompletion later.
>
> I'm working on a project that uses Struts 1.1. So I have a few questions.
>
> #1 - Is autocomplete supported in later version of Struts 1?
No its not supported in any version - Struts only supports attributes that
are in the HTML 4 spec and has a policy of not adding non standard
attributes.
> #2 - If so, which version?
The tags were refactored in Struts 1.2.7 to make creating custom
implementations and adding additional attributes easier. So if you are going
to upgrade then this would be your only option. If you want to do this in
the form tag then something like the following:
public MyFormTag extends FormTag {
protected void renderOtherAttributes(StringBuffer results) {
renderAttribute(results, "autocomplete", "off");
}
}
In the other form "input" tags the equivalent method is
prepareOtherAttributes()
For notes on upgrading and the issues you'll face then there are upgrade
notes on the wiki:
http://wiki.apache.org/struts/StrutsUpgrade
Niall
> I know there are ways to do this with JavaScript. Trapping the enter
> keydown, etc. and doing a submit. I'm doing that currently. The
> problem is that I'm trying to avoid attaching the onkeydown event to
> the body, as many examples have you do, because doing this means that
> even if you're not inside the form you can just hit enter and submit
> the form. So you have to attach the onkeydown event to every form
> field or else somehow check to see if the event was fired by a form
element.
>
> I'm just trying to support this functionality (enter key submits the
> form while in the form, but doesn't save any of the fields' data) with
> minimal headache. It's starting to look like going to autocomplete=off
> might be better, thus my question.
>
> Preston
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
