[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
3:02 a.m.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:03 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399823 ]
Christian Bauer commented on JBSEAM-2652:
-----------------------------------------
Blah, you can escape : in CSS selectors with a backslash.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:12 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399824 ]
Erik Magnusson commented on JBSEAM-2652:
----------------------------------------
Sure, that works in Firefox, but not in IE7.
(I know it works if you use the hex code for : but that is really a bit hackish).
And anyway, I don't think it is too much to ask that components do not generate
unnecessary html elements, such as the <div> in question. Or is it really required
for some reason?
Or at least that Seam provides the same prependId-attribute that standard JSF provides
since 1.2.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:14 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399825 ]
Christian Bauer commented on JBSEAM-2652:
-----------------------------------------
It works just fine in IE7, see http://www.seamframework.org/.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:47 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399833 ]
Erik Magnusson commented on JBSEAM-2652:
----------------------------------------
Actually it doesn't work on http://www.seamframework.org either.
The only ID selectors for prepended IDs you use on that site are:
#searchForm\:searchOptions {
margin-top: 10px;
}
#searchForm\:searchPager {
margin-top: 10px;
}
#userSearchForm\:userListPager {
margin-top: 10px;
}
None of these are actually applied in IE7. Check it yourself with IE Developer Toolbar, or
try some more noticeable styles that make it obvious :)
And anyway, there is no way for me to set the ID of the <div> generated by
<s:decorate>, so I couldn't write an ID selector for <input
id="j_id31:username"> even if I wanted to. Or am I wrong?
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:15 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399844 ]
Pete Muir commented on JBSEAM-2652:
-----------------------------------
Yes the div really is necessary. We didn't just put it there to annoy you.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:15 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=all ]
Pete Muir closed JBSEAM-2652.
-----------------------------
Resolution: Won't Fix
In fact, this is really partially a dupe of JBSEAM-1572, and partially a feature request
for s:decorate to have a new attribute prependId. So I'm closing it.
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:52 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[ http://jira.jboss.com/jira/browse/JBSEAM-2652?page=comments#action_12399861 ]
Erik Magnusson commented on JBSEAM-2652:
----------------------------------------
I apologize if I appeared annoyed :)
By the way, I just noticed that there actually is an undocumented ID attribute of
s:decorate which is propagated to the generated div, so I guess there is a workaround for
the time being if I set my own ID and use the hex code for : in the css id selector.
jsf:
<s:decorate id="userdecorator">
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
css:
#userdecorator\3A username {
background-color: red;
}
A prependId attribute would be nice though, so I guess I'll open a feature request
...
Thanks :)
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:50 a.m.
New subject: [JBoss JIRA] Commented: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
[
https://issues.jboss.org/browse/JBSEAM-2652?page=com.atlassian.jira.plugi...
]
Anthony O. commented on JBSEAM-2652:
------------------------------------
There is no news about this ? Because in 2.2.0.GA that problem still exists, and this is
not duplicated in JBSEAM-1572 ...
Should we open a new ticket ?
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: https://issues.jboss.org/browse/JBSEAM-2652
Project: Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User
name:</h:outputLabel>
<s:decorate>
<h:inputText id="username"
value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register"
action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended
IDs, since the h:form has prependId="false". However, since s:decorate insists
on inserting a superfluous <div> with a generated ID around the <input>
elements it surrounds, those <input> elements end up having prepended IDs from that
<div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div
id="j_id31"><input id="j_id31:username" type="text"
name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div
id="j_id31">), or its insertion into my <input> element's ID
(id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of
s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the
prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the
<s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in
the frameworks are baffling. Why so many superfluous generated html tags? And who thought
of the bright idea of prepending element id attributes using : (colon) as the delimeter??
This effectively cripples the ability to use CSS to style JSF-generated HTML elements with
a simple CSS id selector (since : is a reserved symbol in CSS).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5023
days inactive
6107
days old
8 comments
4 participants
participants (4)
-
Anthony O. (JIRA) -
Christian Bauer (JIRA)
-
Erik Magnusson (JIRA)
-
Pete Muir (JIRA)