I'd say - let's support the usecase when it comes up, so if you still have problems with some non-standardized HTML attributes, tell us, we might go with your solution.
Actually I do think that your solution might be great for especially one tag: the htmlTag. There was a suggestion that we should somehow add the possibility for it to emit arbitrary attributes - we might use your proposed solution to make this happen, what do you think? Along the way, the non-standard support is implemented as well ;) regards, Martin On 11/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ahh -- hadn't seen that approach discussed before. It would have worked in > our situation from my reading of the code. > > 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 > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
