>From: Hermod Opstvedt <[EMAIL PROTECTED]> > > 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. > <<>>
The input markup values in the html forms are identified by the "name" attribute. The decode of the components looks for the clientId in the request parameter map. The components should render the id and name attributes identically. The h:form is defined as a naming container. Naming containers add a prefix to the id of the component. This allows you to include the same presentation fragment several time within the same html form. One of the clay reuse usecases (the person, full person, business) does this but uses subview. > > 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 > Cool. > Hermod > <<>> > Gary > 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. > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * >
