1. The wicket:id is not unique within one document, but the (X)HTML ID has to be. This introduces a lot of problems.
2. The ID given by the user in wicket templates can be used in _javascript_, CSS and such. As such, it has a different meaning for mapping your component hierarchy to your markup file. If a designer wants to alter the ID, he can do so at this moment without worrying about the Java code. When we couple the markup id to the component ID, this no longer holds
3. Having a namespaced wicket:id attribute may not validate correctly with W3C validators, but that doesn't mean they aren't valid. When I include the xmlns:wicket namespace in my documents in my xml editor, all warnings and errors disappear. The w3c validators are meant to validate the *OUTPUT* of Wicket pages, not the pages before they have been processed. It is possible (when we also strip the wicket namespace definition from the documents, as well as the wicket specific tags) to be fully XHTML complient.
4. Removing the wicket:id and substituting it with id will remove our ability to precisely show where there is an error.
Wicket:id *is* not id. If you put 'id' on all your elements, then you are not going to be XHTML compliant: what will happen with the ID when you include a panel in your page?
<wicket:panel>
<span id="foo">Hello, World</span>
</wicket:panel>
<html>
<body>
<span id="panel">Panel goes here</span>
<span id="foo">Another foo message</span>
</body>
</html>
Martijn
On 5/23/06, SourceForge.net <[EMAIL PROTECTED]
> wrote:
Feature Requests item #1493583, was opened at 2006-05-23 13:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1493583&group_id=119783
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 2.0
Status: Open
Priority: 5
Submitted By: Benjamin Hawkes-Lewis (webben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace wicket:id="foo" with id="foo"
Initial Comment:
RECOMMENDATION: DEPRECATE OR SCRAP WICKET:ID
Currently, the inclusion of the wicket:id attribute in
a document uniquely identifies an element from the
document's non-Wicket namespaces for processing by
Wicket, when no other wicket namespaced attribute is
present on that element.
Using this attribute has one major advantage. The
Wicket parser can check that all elements identified
for wicket processing in the document are in fact bound
to some Java code in the document's class.
But using the wicket:id attribute also has grave
disadvantages:
1) It detracts from Wicket's claim that it processes
documents that are similar to "pure-and-simple HTML"
( http://wicket.sourceforge.net/Introduction.html).
2) No DTD can define that a wicket:id attribute must be
unique within a document by typing the attribute as ID.
This is because in XML 1.0, documents can only have
*one* attribute of type ID. Instead, wicket:id would
have to be typed as CDATA, much like the XHTML name
attribute.
3) If designers use the XHTML id attribute heavily for
CSS styling purposes, custom _javascript_, or fragment
identifiers (which permit links to a particular part of
a document, e.g. http://www.w3.org/TR/xhtml1/#h-4.10
where h-4.10 is an id attribute) then a lot of
duplicate typing must be done: e.g. <h2 id="chapter2"
wicket:id="chapter2" />.
The wicket:id attribute is *not* necessary for
"enabling component-oriented, programmatic manipulation
of markup". That could work off existing XHTML id's
just as easily. It is only useful for allowing
documents to *demand* processing from the Wicket
program, in a sort of inverse of the Wicket vision.
That is not necessarily a bad thing, but it could
easily be done in other ways.
For example, wicket:id could be *entirely* replaced
with the existing XHTML id attribute, combined with a
new wicket:parsing="required" attribute when page
authors need to force an error if no code is combined
with an element. For convenience, perhaps Wicket should
check that all form components (i.e. input, select,
textarea, button) have associated code and break with
an error if they don't. The Wicket debug screen could
list id's with and without associated code.
I don't think the alternative solution of generating
XHTML id's from wicket:id's will work. At least one
XHTML elements, map, requires an id attribute (see
http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict).
Being able to add id's and for's to form components is
crucial if page designers are to be able to check their
pages for accessibility and so forth without running
their pages through Wicket first. In sum, having XHTML
id's generated by Wicket breaks exactly the sort of
separation of concerns espoused in the Wicket vision
statement.
-------------------------------------------
APPENDIX: WICKET'S RIVALS AND THE ID ATTRIBUTE
As always, it's worth taking a look at how Tapestry and
JSF handle these issues.
Tapestry binds code components to templates using an
unnamespaced attribute jwcid, where JCW is short for
"Java Web Component" (see
http://jakarta.apache.org/tapestry/UsersGuide/template.html#templates.components.ids ).
Where Wicket sometimes uses special elements to certain
functions (e.g. wicket:remove elements), Tapestry
always uses special values for the jwcid attribute such
as "$remove$". The User Guide says "Tapestry templates
are designed to look like valid HTML files (component
HTML templates will just be snippets of HTML rather
than complete pages). Tapestry 'hides' its extensions
into special attributes of ordinary HTML elements."
Sorry, but the actual upshot is that while Tapestry
HTML templates are mostly made up of standard HTML
elements and attributes, but they do not even *look*
like valid HTML documents. They certainly can't
validate as such. Unsurprisingly, "[t]emplates as
wellformed XML, using a namespace for Tapestry
attributes and elements" is part of Howard Lewis Ship's
vision for Tapestry 5 (see
http://www.nabble.com/Tapestry+5+thoughts-t1035301.html#a268707)
By contrast, JSF just uses the XHTML id's already
present in the template. Where an id is required but
has not been specified by the template, JSF generates
one automatically. Consequently, JSF id attributes are
actually of type ID and XML parsers can expect them to
be unique within a given document. JSF may be a mess,
but IHMO on this particular issue JSF has a technically
superior solution which is much simpler for end-user
designers and developers.
Over you to you folks. What do you think?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1493583&group_id=119783
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
Wicket 1.2 is coming! Write Ajax applications without touching _javascript_!
-- http://wicketframework.org
