My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 128: JMesa's Javascript is implemented as global functions
3 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Oct 2008


 
Reported by bgo...@e1b.org, Jul 29, 2008
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
#1 bgo...@e1b.org
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.
Jul 29, 2008
#2 bgo...@e1b.org
Here are the modified javascript files:
jmesa.js
2.0 KB   View   Download
jquery.jmesa.js
23.4 KB   View   Download
Jul 29, 2008
#3 bgo...@e1b.org
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.
plugin-renderers.patch
26.2 KB   View   Download
Jul 29, 2008
#4 bgo...@e1b.org
(No comment was entered for this change.)
portlet.jsp.patch
1.8 KB   View   Download
Jul 29, 2008
#5 extremec...@gmail.com
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
#6 extremec...@gmail.com
(No comment was entered for this change.)
Status: Accepted
Jul 30, 2008
#7 bgo...@e1b.org
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
#8 extremec...@gmail.com
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
#9 extremec...@gmail.com
(No comment was entered for this change.)
Labels: -Type-Defect Type-Enhancement
Aug 5, 2008
#10 extremec...@gmail.com
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
#11 bgo...@e1b.org
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.
jquery.jmesa.js
23.4 KB   View   Download
Aug 6, 2008
#12 extremec...@gmail.com
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
#13 bgo...@e1b.org
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
#14 extremec...@gmail.com
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
#15 extremec...@gmail.com
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
Project Member #16 jeff.johnston.mn@gmail.com
Done and on the trunk.
Status: Fixed

Powered by Google Project Hosting