Generating id's will come back later to bite you. For example if I have a list with 7 items and wicket will generate id's for it like item_0, item_1, etc what are you going to when the user reorders the list? Are you going to rename item_0 to say item_2 or just change the order in which they are rendered, giving a list that might look like this: item_5, item_0, item_1, item_4, item_2, item_6, item_3. Both solutions could cause problems the first solution with javascripting the second with a style that depends on even and odd item id's.
This is just one example I can think of right now but you can bet there are more problems lurking out there. This is exactly why we should use the wicket attribute users can then make there own id with attribute modifiers any way they want. And if given the option to remove all wicket related attributes/tags the output will be valid for (x)html. The source file might not be valid because of the extra attributes / tags but then again which framework has that? Velocity doesn't neither does jsp just to name a few. Maurice -----Oorspronkelijk bericht----- Van: Gili [mailto:[EMAIL PROTECTED] Verzonden: woensdag 16 februari 2005 1:32 Aan: [email protected] Onderwerp: Re: [Wicket-develop] id of elemets and listviews On Tue, 15 Feb 2005 23:30:46 +0100, Eelco Hillenius wrote: >What do you mean by that previewability is lost? You don't/ can't have >previewability as a framework user of the core components, as the markup >is hidden. Furthermore, the surest way to loose any previewability is to >start using generated ids. I don't think it matters whether IDs are generated or not as long as it is in a deterministic manner. Say I wanted to preview a page containing a table. If the preview markup contains a single row, "myRow1" and at runtime rows get generated with IDs: "myRowX" where X is an incrementing integer value, then I can generate CSS that will work for both the preview and runtime rendering by saying that some style should allow to any component with an ID having the subset "myRow???". I assume one can do that? Anyway, it is just a thought. As long as the behavior is deterministic we should be fine. >And what are ids like >'mypanel_myfirstlist_item2_mysecondlist_link3_linklabel' going to help >you with, besides being complient with the W3C req that ids should be >unique (and with which hardly anyone in the amazing world of web >development complies to anyway)? 'mypanel_myfirstlist_item2_mysecondlist_link3_linklabel' is going to give you deterministic ID generation which will allow you to code up CSS/JS which is guaranteed to continue working so long as you do not modify the hierarchy (it doesn't matter if you add/remove components around it). Currently there CSS/JS that depends on a tag ID is not guaranteed to work properly. I think this is about more than just complying with W3 standards. It's about making sure that when you refer to a component using CSS/JS it actually works. I don't like the idea of using the wicket attribute because it violates the DDT of (x)HTML. We can only inject attributes, tags into our own namespace, not the preexisting one. Gili ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
