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=lt;input type=quot;hiddenquot; name=quot;jscook_actionquot; /gt;/ /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 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. Gary [1] http://issues.apache.org/jira/browse/MYFACES-219?page=com.atlassian.jira.plugin. 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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SV: JSCoockMenu, hidden inputs and name attribute
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=lt;input type=quot;hiddenquot; name=quot;jscook_actionquot; /gt;/ /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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: JSCoockMenu, hidden inputs and name attribute
On 3/27/07, Gary VanMatre [EMAIL PROTECTED] wrote: 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. prependId=true|false 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. I agree. It's a bug in the component. That's where the problem should be fixed.
JSCoockMenu, hidden inputs and name attribute
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]. 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. 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 propose that we in Clay add the ability so set the name as an attribute, and have it retain that value unchanged. [1] http://issues.apache.org/jira/browse/MYFACES-219?page=com.atlassian.jira.plugin.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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
