Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
Problem is when you call getMarkupId(). If you call this method before the first page render, Wicket is not able to get the markup attribute for some components (because of borders and transparent resolvers which break the 1:1 mapping of component tree - markup. -Matej On 7/26/07, Scott Swank [EMAIL PROTECTED] wrote: How hard would it be to add a method like useHtmlElementId()? It would default to false, but when a component returns true then the element id from the template would be used. Scott On 7/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote: 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 -- Scott Swank reformed mathematician - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
I'm a little surprised this isn't more of a high priority item... It is scheduled as major, with fix version beta 3. That's a pretty high priority. The fact is though that until I stumbled upon this, we had no complaints of users to deal with in this matter. 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 ??) Yes, of course. It's one of the things that is very difficult to solve for us, sorry. Software can be like that. Solving this properly was one of the main reasons for the constructor change (which introduced other problems which in the end we deemed more serious than what the constructor change fixed). This cost us months of work we had to throw away in the end. So please don't tell us we haven't been trying. The main problem here is that we need the markup loaded, and at this time at least, we need to get back to the page for that to resolve things like markup inheritence, borders, etc. But without forcing passing in parents like we did with the constructor change, we can't be sure when the whole hierachy is built, and we thus can't support getMarkupAttributes in the constructor/ before rendering. So.. at this time we could only support a half-baked solution, which simple won't do. We need to find a good solution, which is what the issue is open for. As always, patches are welcome. Eelco - 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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
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. Eelco - 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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
On 7/26/07, Kirk Israel [EMAIL PROTECTED] wrote: (I started moving myself to the other list but am not quite there yet) Empirically, it looks like there might have been a change in behavior from 1.2, but I couldn't verify that on http://cwiki.apache.org/WICKET/migrate-13.html -- if you're writing custom javascript (in this case an arbitrary form element that needs to submit a hidden form for an ajax interaction), is there a way that preserves the id as set in the .html wicket:id=XYZ as the HTML element's id? In this case, when the .html is processed by Wicket, the resulting id is something like XYZ6 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 Googling on wicket getElementById it seems that might be deprecated for javascript inside Wicket, there's that Wicket.$(id) syntax instead? But I couldn't find documentation on that, and both getElementById() and Wicket.$() worked with XYZ6 but not the original XYZ. tbh, you are not meant to use anything inside wicket-ajax.js directly. -igor Pointers to the documentation I wasn't able to find appreciated as well as direct advise and or corrections of assumptions ... Thanks! - 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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
How hard would it be to add a method like useHtmlElementId()? It would default to false, but when a component returns true then the element id from the template would be used. Scott On 7/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote: 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 -- Scott Swank reformed mathematician - 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
Re: [Wicket-user] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
Would it make sense to override the method on border (et al), make it final, and just have it always return false? Or does the 1:1 problem lie with components within such a border? On 7/26/07, Matej Knopp [EMAIL PROTECTED] wrote: Problem is when you call getMarkupId(). If you call this method before the first page render, Wicket is not able to get the markup attribute for some components (because of borders and transparent resolvers which break the 1:1 mapping of component tree - markup. -Matej On 7/26/07, Scott Swank [EMAIL PROTECTED] wrote: How hard would it be to add a method like useHtmlElementId()? It would default to false, but when a component returns true then the element id from the template would be used. Scott On 7/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote: 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] Wicket 1.3, use of getElementById and Wicket.$() and the preservation of ids
(I started moving myself to the other list but am not quite there yet) Empirically, it looks like there might have been a change in behavior from 1.2, but I couldn't verify that on http://cwiki.apache.org/WICKET/migrate-13.html -- if you're writing custom javascript (in this case an arbitrary form element that needs to submit a hidden form for an ajax interaction), is there a way that preserves the id as set in the .html wicket:id=XYZ as the HTML element's id? In this case, when the .html is processed by Wicket, the resulting id is something like XYZ6 Googling on wicket getElementById it seems that might be deprecated for javascript inside Wicket, there's that Wicket.$(id) syntax instead? But I couldn't find documentation on that, and both getElementById() and Wicket.$() worked with XYZ6 but not the original XYZ. Pointers to the documentation I wasn't able to find appreciated as well as direct advise and or corrections of assumptions ... Thanks! - 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
