Hi See comment inline bwlow
-----Opprinnelig melding----- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 27. mars 2007 17:51 Til: dev@shale.apache.org Emne: Re: JSCoockMenu, hidden inputs and name attribute >From: <[EMAIL PROTECTED]> > > Hi > > In my quest for better samples and documentation, I have started creating sample > Clay configurations for the variuos Tomahawk components. I have run into an > issue that has made me scratch my head a bit. > > First there is an issue[1], [2] with the Tomahawk JSCoockMenu and the inner > form. There is a workaround for this that can be achieved if you code the menu > in Clay-HTML style as outlined in [2]. You mean something like this: <span jsfid="ignore"> <input type="hidden" name="jscook_action" /> </span> >Now trying to achieve the same in XML is > however not that easy. The reason being that you can not set the "name" > attribute of the inputHidden component in such a way that is does not get > mangled with an "id....." in front of it when it gets rendered. > I see what you mean. A JSF inputSecret would behave like any other component. I have a couple ideas to try. We could try using the "clayOut" to generate makup that is ignored by the html to component mappings. <component jsfid="t:jscookHidden" extends="clayOut"> <attributes> <set name="escapeXml" value="false"/> <set name="value" value="<input type="hidden" name="jscook_action" />"/> </attributes> </component> Another option might be to use the tomahawk t:inputSecret. It has a forceId option that ignores naming containers. <component jsfid="t:jscookHidden" extends="t:inputSecret" id="jscook_action"> <attributes> <set name="forceId" value="true"/> </attributes> </component> > This leads me to wonder: Does the "name" attribute have to follow the naming > scheme of the id's? As far as I can tell it is not need when building/restoring > the component tree, so it should be possible to set it to some name and have its > name remain untouched. If is has not been specified, then the renderer is free > to do what ever it wants. I have noticed that the only components that get a > "name" rendered by default are forms and hidden inputs. For the form I can see > why one needs a "name" attribute, but not for the hidden inputs. > I think it becomes an issue if you are using the same component by id within the same naming container. But, I think that there are several efforts to solve the problem. The Trinidad tr:form component is not a naming container. This means that the components added to the trinidad form component will not be prefixed with the form name. The tomahawk components have the forceId. I want to say that JSF 1.2 has something similar but I might be making that up. <<>> I am not referring to the id, but to the "name". I ail to see why that has to go into the componenttree idenitifaction scheme. <<>> I don't think this is something that Clay can solve. It's the components responsibility to render markup. Clay only glues them together. > I propose that we in Clay add the ability so set the name as an attribute, and > have it retain that value unchanged. > IMO, unless we can find another scenario, I'd rather not make changes just to make this one component work. The component should be renderering the hidden attribute if it is needed by the component. <<>> As you can see from a later mail, it's been fixed in tomahawk 1.1.6-SNAPSHOT, so I'm happy with that Hermod <<>> Gary > > [1] > http://issues.apache.org/jira/browse/MYFACES-219?page=com.atlassian.jira.plu gin. > system.issuetabpanels:all-tabpanel > [2] http://www.mail-archive.com/dev@myfaces.apache.org/msg20819.html > > Hermod > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > This email with attachments is solely for the use of the individual or > entity to whom it is addressed. Please also be aware that the DnB NOR Group > cannot accept any payment orders or other legally binding correspondence with > customers as a part of an email. > > This email message has been virus checked by the anti virus programs used > in the DnB NOR Group. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
