Just to confirm that this works, we applied this patch on the BETA6 snapshot (it doesn't patch automatically anymore, but the changes are intuitive).

I definitely second the suggestion to rewrite it to create the table using plain Javascript (either with innerHTML or DOM) rather than google-closure. We are not using closure in our project, so we have added it solely for this purpose.

Robert Peterson
added a comment - 06/Mar/10 21:22 Just to confirm that this works, we applied this patch on the BETA6 snapshot (it doesn't patch automatically anymore, but the changes are intuitive).
I definitely second the suggestion to rewrite it to create the table using plain Javascript (either with innerHTML or DOM) rather than google-closure. We are not using closure in our project, so we have added it solely for this purpose.

Patch attached with minor fix from previous version. This file does not include the Google Closure dependency, which will need to be downloaded from http://code.google.com/closure/ in order to run this.

Benjamin McCann
added a comment - 03/Dec/09 00:17 Patch attached with minor fix from previous version. This file does not include the Google Closure dependency, which will need to be downloaded from http://code.google.com/closure/ in order to run this.

Yeah, both library itself and the compiler are pretty cool. I ran a portion of the Shindig code through the compiler not too long. There were only a few errors when I tried and I submitted most of them back to Shindig, so it should be pretty easy to get it to compile.

Benjamin McCann
added a comment - 05/Nov/09 21:32 Yeah, both library itself and the compiler are pretty cool. I ran a portion of the Shindig code through the compiler not too long. There were only a few errors when I tried and I submitted most of them back to Shindig, so it should be pretty easy to get it to compile.

Right, it's just DOM manipulation and certainly could be done without the DOM helper. However, it would be extremely tedious and verbose code. I wrote it like this for another project I'm working on and thought I would contribute it back. You're welcome to change it to remove the dependency, but I unfortunately don't have time to myself. And like I said, the resulting code wouldn't be fun or pretty, so I'm not sure you'd wan to.

Benjamin McCann
added a comment - 31/Oct/09 01:03 Right, it's just DOM manipulation and certainly could be done without the DOM helper. However, it would be extremely tedious and verbose code. I wrote it like this for another project I'm working on and thought I would contribute it back. You're welcome to change it to remove the dependency, but I unfortunately don't have time to myself. And like I said, the resulting code wouldn't be fun or pretty, so I'm not sure you'd wan to.

Provides a JS implementation of the gadgets setting menu. Removes dependency upon gmodules.com and prefs dialog now loads instantaneously instead of taking a second or so. Also provides a much better UI by replicating the DOM structure and CSS used by iGoogle.

Benjamin McCann
added a comment - 29/Oct/09 23:16 Provides a JS implementation of the gadgets setting menu. Removes dependency upon gmodules.com and prefs dialog now loads instantaneously instead of taking a second or so. Also provides a much better UI by replicating the DOM structure and CSS used by iGoogle.

However, it does not support the user preference of type list. Instead of giving the add and x buttons that you get in iGoogle, you just get an input of type text. This basically means you can only input one item (unless you know to separate them using a pipe). It'd probably be pretty easy to extend this to accept commas and then replace them with pipes when submitting the form. Given that the current implementation seems to be worse (https://issues.apache.org/jira/browse/SHINDIG-1212), I'm not sure list support is that big of an issue. If including the library above and having somewhat bad list support is okay, then I can clean it up and submit a patch.

Benjamin McCann
added a comment - 29/Oct/09 07:42 I have a JS implementation that creates the preferences dialog using the functions in this library:
http://code.google.com/p/doctype/source/browse/trunk/goog/dom/dom.js
However, it does not support the user preference of type list. Instead of giving the add and x buttons that you get in iGoogle, you just get an input of type text. This basically means you can only input one item (unless you know to separate them using a pipe). It'd probably be pretty easy to extend this to accept commas and then replace them with pipes when submitting the form. Given that the current implementation seems to be worse ( https://issues.apache.org/jira/browse/SHINDIG-1212 ), I'm not sure list support is that big of an issue. If including the library above and having somewhat bad list support is okay, then I can clean it up and submit a patch.

Benjamin McCann
added a comment - 15/Oct/09 01:52 Whoops, my bad. It looks like you did fix this. It's just not showing up yet in the web view for some reason ( http://svn.apache.org/repos/asf/incubator/shindig/trunk/javascript/container/gadgets.js )
Thanks! I'm fine if you close this issue.

I don't think we should close this issue. We either need to not point to gmodules at all as Kevin Brown suggested, which is a larger work item. Or for the meantime we should change the call to gmodules.com to point to www.gmodules.com, which would be a trivial change. This is unusably slow right now because we're pointing at the wrong domain and it's really simple to fix.

Benjamin McCann
added a comment - 15/Oct/09 01:33 I don't think we should close this issue. We either need to not point to gmodules at all as Kevin Brown suggested, which is a larger work item. Or for the meantime we should change the call to gmodules.com to point to www.gmodules.com, which would be a trivial change. This is unusably slow right now because we're pointing at the wrong domain and it's really simple to fix.