I'm not disagreeing. Open a vote thread on dev summarizing
everything on this thread and your reasoning. Just be aware that the
JSF RI (which is considered to be the spec in code format) was the
originator of _id.
On 4/19/07, Rudi Steiner <[EMAIL PROTECTED]> wrote:
Hi Mike,
if I understand it right, in the JSF-spec is wirtten, that the Impl
must render HTML 4.01 and with an id starting with _ the output is not
HTML 4.01.
So I think to be Spec-conform the _ must be removed as a prefix.
best regards,
Rudi
On 4/19/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> _<var> is a long-standing convention that represents a framework-level
> (not an application-level) variable. Also _id is has been in use now
> for a long enough time as the standard that most people are aware of
> it.
>
> I'm not against changing it -- I'm just letting you know what the rational is.
> Your best bet is probably to bring it up for a vote on the MyFaces dev
> list after explaining the issue.
>
> Another possibility is to make UIViewRoot.UNIQUE_ID_PREFIX
> configurable in the web.xml file as a parameter. It's not marked
> final in the java docs, so that should be allowed. Then each user can
> make their own determination if the default doesn't meet their needs.
> For example, I'd probably consider making it "q" because I'd want it
> to be as short as possible, Iand I'm unlikely to use q<number> as an
> id value :-)
>
> This kind of brings up another issue. It's not necessarily enough to
> make the prefix identifier unique for your own application. It'd also
> have to be unique for any 3rd party components you might use that have
> hardcoded ids (not really sure if this ever happens, but maybe it
> does).
>
> static java.lang.String UNIQUE_ID_PREFIX
>
>
> On 4/19/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> > Well, could use mf_id (mf standing for MyFaces), you cannot be sure at 100%
> > that it will be unique, but neither can you with _id imho.
> >
> >
> > On 4/18/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > I don't see anything that prevents someone from changing the unique
> > > prefix value, but it'd be difficult to come up with a short yet
> > > guaranteed-to-be-unique alternative, considering that the spec only
> > > allows characters, -, and _ as symbols.
> > >
> > > From the spec:
> > >
> > > 3.1.1 Component Identifiers
> > > Every component may be named by a component identifier, which (if
> > > utilized) must be
> > > unique among the components that share a common naming container parent in
> > a
> > > component tree. Component identifiers must conform to the following rules:
> > > They must start with a letter (as defined by the Character.isLetter()
> > > method) or underscore ('_').
> > > Subsequent characters may be letters (as defined by the
> > > Character.isLetter() method), digits as defined by the
> > > Character.isDigit() method, dashes ('-'), and underscores ('_').
> > > To minimize the size of responses generated by JavaServer Faces, it is
> > > recommended
> > > that component identifiers be as short as possible.
> > > If a component has been given an identifier, it must be unique in the
> > > namespace of
> > > the closest ancestor to that component that is a NamingContainer (if any).
> > > public String getId();
> > > public void setId(String componentId);
> > >
> > > Also,
> > >
> > >
> > http://java.sun.com/javaee/javaserverfaces/1.1/docs/renderkitdocs/
> > >
> > > General notes regarding the id attribute
> > >
> > > All components, and therefore all tags for those components
> > > support the id attribute. This attribute is optional. If not present
> > > its value is autogenerated by the implementation and used for internal
> > > purposes only. If present, an id attribute must not start with the
> > > String listed as the value of the constant
> > > UIViewRoot.UNIQUE_ID_PREFIX, and it must be unique within the scope of
> > > the nearest component that is a NamingContainer.
> > >
> > > All renderers must take the following action regarding theid
> > > attribute: If the value returned fromcomponent.getId() is non-null and
> > > does not start with UIViewRoot.UNIQUE_ID_PREFIX,
> > > callcomponent.getClientId() and render the result as the value of the
> > > id attribute in the markup for the component. See the javadoc
> > > forcomponent.getClientId() for details, particularly note that the
> > > Renderer has a chance to modify the client id before it is rendered.
> > > If the component doesn't generate any markup elements, include the id
> > > attribte on a "span" element that encloses the content for the
> > > component.
> > >
> > > In addition to any action already specified in the renderers,
> > > all renderers for UIInput components must take the following action
> > > regarding the id attribute: Callcomponent.getClientId() and render the
> > > result as the value of the name attribute. This may cause some
> > > renderers to have "id" and "name" attributes that have exactly the
> > > same value.
> > >
> > > On 4/18/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> > > > Actually, that very specific error also gives me headache too, but it
> > come
> > > > directly from the official API. See UIViewRoot.createUniqueId() and
> > > > UIViewRoot.UNIQUE_ID_PREFIX.
> > > >
> > > > That being said, the spec does not forces the value of UNIQUE_ID_PREFIX
> > > > (which is _id in the RI API) so I guess MyFaces could give it another,
> > HTML
> > > > 4.01 compliant value, and I sure hope so.
> > > >
> > > >
> >
http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/component/UIViewRoot.html
> > > >
> >
http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/constant-values.html#javax.faces.component.UIViewRoot.UNIQUE_ID_PREFIX
> > > >
> > > >
> > > > Regards,
> > > >
> > > > ~ Simon
> > > >
> > > >
> > > >
> > > > On 4/18/07, Rudi Steiner <[EMAIL PROTECTED]> wrote:
> > > > > On 4/16/07, Mike Kienenberger < [EMAIL PROTECTED] > wrote:
> > > > > > From the JSF 1.1 spec:
> > > > > > =============================
> > > > > > 8.5 Standard HTML RenderKit
> > > > > > Implementation
> > > > > > To ensure application portability, all JSF implementations are
> > > > > > required to include
> > > > > > support for a RenderKit, and the associated Renderers, that meet the
> > > > > > requirements defined in this section, to generate textual markup
> > that
> > > > > > is compatible
> > > > > > with HTML 4.01.
> > > > > > =============================
> > > > > >
> > > > > > However, if there are changes we can make to MyFaces Core that will
> > > > > > improve xhtml support while still meeting the above requirement, we
> > > > > > can make them.
> > > > > >
> > > > > >
> > > > > > On 4/16/07, Rudi Steiner < [EMAIL PROTECTED]> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > making some investigations on XHTML-comfomance fo myFaces (without
> > > > > > > Tomahawk) I found out, that the output of the basic components,
> > like
> > > > > > > <h:form/>, <h:commandButton/> and so on render valid XHTML but
> > just
> > > > > > > transitional (<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
> > > > > > > Transitional//EN"
> > > > > > > "
> > > >
> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>).
> > > > > > >
> > > > > > > The problem is, that our customer requires XHTML-Strict (<!DOCTYPE
> > > > > > > html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> > > > > > >
> > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd ">).
> > > > > > >
> > > > > > > Running the XHTML-output of a standard form against the validator
> > of
> > > > > > > the W3C. I get some errormessages.
> > > > > > >
> > > > > > > The first one ist, that there is no name-attribute in the defined
> > DTD
> > > > > > > for the form-element, but the <h:form/>-tag renders it:
> > > > > > >
> > > > > > > <form id="_idJsp2" name="_idJsp2" method="post" action=
> > > > > > >
> > > > > > > The second error is, that the hidden fields inserted by the
> > > > > > > JSF-implementation into the form are not enclosed in a
> > div-Element. If
> > > > > > > I but my input-Elements inside the form in a <t:div/>, this
> > elements
> > > > > > > are enclosed in a <div> and don't produce any errors, but the
> > hidden
> > > > > > > fields inserted by myfaces are rendered after the closing
> > </div>-Tag.
> > > > > > >
> > > > > > > Has anyone an idea? Isn't it required by the JSF-Spec to render
> > > > > > > XHTML-Strict to be a standard conform implementation?
> > > > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Rudi
> > > > > > >
> > > > > >
> > > > >
> > > > > Hello Mike,
> > > > >
> > > > > I tested the generated output of a <h:form/> with the following
> > doctype
> > > > >
> > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> > > > > "http://www.w3.org/TR/html4/loose.dtd";>
> > > > >
> > > > > with the validator at http://validator.w3.org/ . The validator
> > > > > generates a lot of errors, for example this one:
> > > > > Line 20 column 11: value of attribute "ID" invalid: "_" cannot start a
> > > > name.
> > > > > <form id="_idJsp4" name="_idJsp4" method="post"
> > > > action="/Pro/createPerson.jsf"
> > > > >
> > > > > Changeing the Doctype of the same markup to
> > > > >
> > > > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> > > > >
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
> > > > ">
> > > > >
> > > > > the markup passes validation.
> > > > >
> > > > > Does this mean, that myFaces is not Spec-conform, given that the spec
> > > > > says HTML 4.01 must be generated?
> > > > >
> > > > > Best regards,
> > > > > Rudi
> > > > >
> > > >
> > > >
> > >
> >
> >
>
