| Issue 128: | JMesa's Javascript is implemented as global functions | |
| 3 people starred this issue and may be notified of changes. | Back to list |
As of version 2.3.3 all of JMesa's javascript is placed into the global namespace, leaving a lot of room for namespace collisions (however unlikely that may be). It would be nice if it were implemented as a jQuery plugin instead, with an optional adapter for backwards compatibility. As discussed in the group, the API's generated scripts would utilize the plugin instead of the global functions. Existing client code should run unmodified.
Jul 29, 2008
Here are the modified javascript files:
Jul 29, 2008
I modified the HTML view renderers to utilize the plugin instead. Attached is a patch. All of the JMesa examples seem to work fine, but some more widespread testing would be nice. I modified the portlet example to use the plugin to set 'invokeAction' and 'invokeExportAction', but not the others.
Jul 29, 2008
(No comment was entered for this change.)
Jul 29, 2008
Thanks! Unfortunately I have guests coming in this week so I might not be able to really look at this until early next week. You do work fast, which is great because I can see another release of JMesa going out mid August already :).
Jul 29, 2008
(No comment was entered for this change.)
Status:
Accepted
Jul 30, 2008
Thanks for considering this Jeff... you were a great help when we started using extremetable, and you've been even more helpful with JMesa. I'm usually pretty wary of yoking my applications to external dependencies (I'm not even using Spring yet), but because of your support I had no qualms about taking the risk. This enhancement is a major change that will make it feasible for us to JMesa in a portal environment. Hope you have a good week, and thanks again!
Jul 30, 2008
No problem...your doing all the work though so I should be thanking you :). I'll still be around this week and checking the groups, but I won't have time to dig into your patch at all.
Jul 30, 2008
(No comment was entered for this change.)
Labels:
-Type-Defect Type-Enhancement
Aug 5, 2008
I started looking at your plugin code today. I can tell you spent a long time working on this! I need (want) to learn how you did this but I do not know anything about writing a jQuery plugin. How did you go about learning this? Do you have any links that you could point me to or did you just get the information off the jQuery site? The JMesa war examples do not work right now either with the original onInvokeAction() methods. Should they be working?
Aug 6, 2008
This link is what I based the plugin off of: http://docs.jquery.com/Plugins/Authoring Also, I had a bug in jquery.jmesa.js, line 631. Here is the modified file... Sorry. I tested this against the examples and it is working now.
Aug 6, 2008
I think you did an amazing job on this plugin! I have been playing with it for quite a while tonight. At first I didn't get what some of it was doing but then I see you did a lot of work to ensure that things would be backwards compatible. I still have some things to figure out but for the most part I understand it now. For sure we will need to use this :). I am trying to think of the easiest way to roll this out now. My initial thoughts are to not change the Java code but include this as the distribution JavaScript in the next release. That way we can get more feedback and it would be easy for developers to roll back to the previous version if they need to. Then, depending on the feedback, we could move in the Java code changes. It would also make sense to make those WebContext changes we talked about in a different post. At that point I would move up to a full 2.4 release.
Aug 7, 2008
I think that is a good plan. What is the road map like? Are you thinking that 2.3.4 will be the last revision before 2.4? Maybe you could cut a release without the Java changes like you describe above, and then check the renderer changes into trunk, if you think that's appropriate?
Aug 7, 2008
Yes, that is exactly what I was thinking as well. Ideally the (unofficial) road map is that the next release would go out with the retro tags. If that is feasible in the next few weeks I would wait. If not then I would just include the tags in the 2.4 release (or when they get done).
Aug 8, 2008
I am also going to be checking in the JavaScript files this weekend. It just occurred to be that I have not checked them into the trunk yet.... For now I will just place the java patches in the resource folder until they are applied.
Oct 19, 2008
Done and on the trunk.
Status:
Fixed
|
Here is my first stab at solving this problem. I ported jmesa.js to jQuery and placed it in the file jquery.jmesa.js (that is how jQuery plugins are named, i think). I had to make some strange decisions to get it to where it is, but I am happy with the end result. Basically, I took all of the formally global functions and placed them under the $.jmesa namespace. The functions that take the table ID as the first parameter are then 'jQuery-ized' so that you can do things like this: $('#jmesa-table').setExportToLimit('').createHiddenFieldsAndSubmit() Under the hood, the same jmesa.js functions are still used, but the jQuery version of the function automatically passes the table ID as the first parameter, and then the other arguments are added in order and passed as well. Any of the top-level members of the former jmesa.js can be accessed using $.jmesa.whatever (new $.jmesa.Limit(), $.jmesa.addTableFacadeToManager('jmesa-table'), etc.) Two members are added to the 'document' object, so that the Java API does not have to depend on the presence of the '$' or 'jQuery' variables in the global namespace (see jQuery.noConflict(boolean)). These are: document.jmesaTableFor(something) - takes a jQuery expression (string) or DOM node as a parameter. If the first argument is a string, the first node that is matched is used. If the node is the top-level table node of a JMesa table, $(node) is returned. Otherwise, the node's parents are searched for the JMesa table node and $(table) is returned. document.jmesa - An alias for the $.jmesa namespace (JMesa static functions and classes) Also attached is a new version of jmesa.js, that is for backwards compatibility. It is my feeling that if users are familiar with jQuery, over time existing client code should be modified so that this file is not needed. If jquery.jmesa.js is not already included in the page, we attempt to download it with an XHR call. The script then simply copies all of $.jmesa into the global namespace (to mimic the behavior of the old jmesa.js). Best practice would be for users to add jquery.jmesa.js to the page using script tags so that AJAX is not needed. Although the solution may seem a bit convoluted, even if more functions are added to jquery.jmesa.js, they will be available to users still using jmesa.js. Additionally, if users are not familiar with or comfortable with jQuery, they can simply continue to use jmesa.js as a wrapper around the jQuery plugin to hide the dependency on that library.