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:
>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.
Another option might be to use the tomahawk t:inputSecret. It has a forceId
option that ignores naming containers.
> 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.
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
