I can see the reasons where the problems stem with repeaters, and that is a valid usecase. However, not all components are created inside repeaters, and writing javascript for a particular page is a common usecase as well. We need to find some middle ground here.
The problem I have is that the current setup requires you to override getMarkupId() on all components that have a static id. However, this does not play nicely with behaviors that want to bind to the component, these set the flag to autogenerate (which is nice if you don't write your own javascript). Overriding the onBind on the behavior still doesn't work, because the onComponentTag calls getMarkupId(), which autogenerates when the MARKUP_ID_KEY meta data key is not set. It is impossible to set the metadata from the behavior, as MARKUP_ID_KEY is private, thus making it impossible for Wicket ajax to work with static markup id's. Martijn On 3/26/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
The current implementation of getMarkupId() is pretty dumb. It doesn't check if the user already has put a markup identifier in the page. This does not play nicely with page based, custom written javascript. I have several components of which I perfectly know that their id is unique, and reference them from javascript in the markup. Now if I attach a wicket ajax behavior to the component, I suddenly loose the markup identifier because Wicket insists on generating a unique one for me. Can we at least check if the component already has a markup attribute 'id', and if so, leave it alone? Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
-- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
