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
