The autocomplete binding was the one that drove our need in this case.
The general use case I was looking to support with the proposal was a tag-level approach to supporting nonstandard attributes (i.e., no coding), without "endorsing" them by adding first-order attributes to the tags.
Steve
On 11/24/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Hmm, in fact, the "autocomplete" attribute is supported during
rendering of components - we needed that for customized drop-down
lists.
So you could do a component binding, and add the autocomplete
attribute to the componentAttributesMap, and the renderer will render
the corresponding attribute, if I don't fool myself right now ;).
Is there any other special extension that comes to your mind?
regards,
Martin
On 11/24/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Here's the specific scenario that led me down this path.
>
> The app I'm working on is used by call center reps to enter orders, which
> include credit card numbers. The autocomplete feature in most modern
> browsers will cache previous entries in fields. We didn't (for obvious
> reasons) want this to happen, and adding the autocomplete="off" attribute to
> the input tag is the most straightforward way to do that.
>
> There are only a few fields out of the many many fields in this app that
> require this attribute. XSLT seems like an awfully heavy hammer to bring to
> bear on this problem.
>
> Steve
>
>
> On 11/23/05, Korhonen, Kalle < [EMAIL PROTECTED]> wrote:
> >
> > Doesn't look too clean to me.. If you need those non-standard attributes
> for specific tags (possibly with certain values), why not just write a
> filter that would do an XSL transformation and add them to the response?
> >
> > Kalle
> >
> >
> > ________________________________
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ]
> > Sent: Wednesday, November 23, 2005 8:19 AM
> > To: [email protected]
> > Subject: Nonstandard HTML attribute support
> >
> >
> >
> > A couple days ago our project ran into the need to emit nonstandard HTML
> attributes to support a certain security-related feature. We ended up
> > subclassing HtmlInputTextTag to add a setter/getter for the attribute.
> While it's not a lot of code, a "standard" method for adding these sorts of
> attributes
> > seems like it would be desirable.
> >
> > I'll start by recognizing that I might be stepping into a religious battle
> over support for nonstandard HTML tags. If so, I apologize in advance ;>)
> >
> > I'm also open to the idea that there's already a way to do this, but I
> haven't been able to find it. RTFM comments welcome.
> >
> > --
> >
> > The approach I'll propose for discussion is a new Tomahawk tag called
> t:nonstandard-attributes. Its children would be f:param elements that would
> specify name-value pairs to be added to the attribute list of its parent.
> >
> > Sample usage would be:
> >
> > <t:inputText id="credit_card_number"
> value="#{backingBean.creditCardNumber}">
> > <t:nonstandard-attributes>
> > <f:param name="autocomplete" value="false"
> >
> > </t:nonstandard-attributes>
> > </t:inputText>
> >
> > At first glance, this tag would modify the behavior of:
> >
> > commandButton
> > commandLink
> > dataTable (for HTML table)
> > form
> > graphicImage
> > All input* tags
> > outputFormat (causes/modifies the span)
> > outputLabel
> > outputLink
> > outputText (causes/modifies the span)
> > panelGrid (for HTML table)
> > panelGroup (causes/modifies the span)
> > all select* tags
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
