I see what you mean. I'll give this some more thought. For now
we should leave this problem up to the developer (like you mentioned)
and handle parsing at a later time.PS: Now that I think about it, I don't think I have ever seen namespacing for JS before. I just Googled it a bit and I'm 99% it doesn't even exist. Although I did find the following: http://www.netalive.org/swsu/archives/2004/11/namespaces_in_j.html It seems to me we don't need to parse any code. We just need to surround it with a "var namespace1 = { }" code sniplet. And then from the code that refers to the function they need to simply prefix the function name using "namespace1". Now.. Generating the first part (var namespace1) is easy. The hard part is inserting "namespace1." in front of all the JS calls. That breaks down to two use-cases: 1) one JS function refers to another within the same "namespace". Do we need to prefix the function name? I'm hoping not. 2) HTML code refers JS function. This is rather simple stuff like "onMouseClick=<call some function>" which we should be able to easily parse. Again we need a simple use-case before we can comment on this further. I'm thinking maybe we force the users to have this in their code: onMouseClick="<wicket:JS-namespace>.myFunction(arg1, arg2)" That is, there is partial burden on Wicket and partial burden on the user to make this work. Another concern is previewability. I'm not sure how much we can do in this department... Ideas? Gili On Sat, 12 Feb 2005 16:16:00 -0800, Jonathan Locke wrote: > >the problem is dealing with component merging. two components have >named a method or variable the same thing. if we actually parse the JS, >we can add a "namespacing" prefix to these names and ensure that no >collisions will ever occur. what's more, if we do this, we can also >keep the JS code simple and readable (which is often a problem with JS >as it is). > >Gili wrote: > >>On Sat, 12 Feb 2005 15:07:21 -0800, Jonathan Locke wrote: >> >> >> >>>btw, did my comments below make sense (about automatically dealing with >>>CSS and JavaScript)? we'd need to do some work in the parser, but it >>>seems like the right thing (unless i'm missing something...) >>> >>> >> >> I didn't understand the bit about why we need a special parser >>for scoping or something . . . Why can't we just dump the JS into place >>like we currently dump the HTML into place without validating it or >>messing around with its scope? >> >>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_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_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
