the general problem here is that hardcoding ids into wicket markup is mostly dangerous because things are so reusable.
if you put an id into a repeater then it will be repeated all the time - causing multiple elements with the same id - which will lead to invalid html. hardcoding an id inside a panel or a fragment will lead to the same problem. it isnt something obvious until you start reusing code and then it gets nasty all of a sudden. so my two cents are to discourage this. however, as a workaround for cases where you _must_ do this we have component.setmarkupid(string) in trunk - you can use that to force any id you want. -igor On 7/26/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > On 7/26/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > http://issues.apache.org/jira/browse/WICKET-694 > > > i guess there were problems when implementing this, maybe eelco can > > > ellaborate more on the "unforeseen side effects" > > > > Yeah, they were listed in the thread that is mentioned in the issue: > > > http://www.nabble.com/Re%3A-getMarkupId-doesn%27t-return-the-id-from-the-markup-p11294903.html > > > > I don't really know what to do with it tbh. I hope someone else has > > some suggestions. > > I'm a little surprised this isn't more of a high priority item... I > know Repeaters et al might need some special casing, but could the > "usual" cases do what the coder probably expects, i.e. if you specify > in html markup, that id is preserved (and therefore usable in > javascript's getElementById ??) > > Or... I'm not sure what else might depend on that Id as it gets spit > out into what's finally sent to the browser, but maybe there could be > a some kind of mapping function in javascript, > .getElementByWicketId(id)? and > getRepeaterElementByIdAndIterationNumber(id,num) > (I tend to make my function names a bit long :-) > > As a thinking point, my group has come up with 3 possible workarounds > until the real solution appears: > * temporary, awful hack bandaid currently in use: our javascript > getElementById added a "6" to the id... the fragile nature of this > "fix" is not lost on us > * go through some function along the lines of getElementByPrefixOfId() > , so we can get what was specified > * every form has a hidden field like <input type="hidden" > name="OUR_ID" value="XYZ">, and then we have a specific > getFormByOurId() > > Again, I'm not sure what getMarkupId(Component) is called by, if it's > mostly wicket internal use or what... most of what I've talked about > here is javascript workarounds, though i guess the underlying Java > equivalents should be obvious. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > IMPORTANT NOTICE: > > This mailing list is shutting down. Please subscribe to the Apache Wicket > user list. Send a message to: "users-subscribe at wicket.apache.org" and > follow the instructions. > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ IMPORTANT NOTICE: This mailing list is shutting down. Please subscribe to the Apache Wicket user list. Send a message to: "users-subscribe at wicket.apache.org" and follow the instructions. _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
