I understand.

To make things a little easier (and to help with the step-by-step), I've simplified things a little. I've just checked in a new version in my fork of the grid. There are now two branches. "master" and "newapi".

On the master branch, I've added a function $.jgrid.extend() which extends both $.fn and $.fn.jqGrid with its argument. I've also changed every call to $.fn.extend into a call to $.jgrid.extend, and also modified $.fn.jqGrid to handle string arguments as before.

The upshot is that there's only a small number of changes, but it supports the new calling convention ( .jqGrid("method",args) rather than .method(args)). But it doesnt allow you to turn off the "old" calling convention (because the grid itself still uses that).

Then, on the "newapi" branch, I've also changed all the call sites to those functions to use the new calling convention. Obviously, a lot more changes, and much harder to verify.

Im hoping you can pull in the master changes before too long. Once those are in, I should be able to keep the newapi branch up to date fairly easily (I have a script to convert between the two calling conventions).

Hopefully, in the long run, you'll take the newapi changes too - but I can see that thats going to be harder.

Mark

Thanks. I see the code in GitHub. Also I plan to implement this, but need to make it step by step - need to test it.

Thanks

Best Regards

Tony

If you look at my changes (better yet, try them out), you will see that existing code works *without any modification*.

In addition, you can use the new syntax ( $(selector).jqGrid("method",args) rather than $(selector).method(args) ). But its not required.

The only time users need to make a change is if they want to get rid of the old syntax, in order to prevent the existing namespace pollution.

In that case, they set $.jgrid.no_legacy_api=true, and then they *only* get the new syntax.

So once again - there is /no/ breakage of existing code with these changes.

And yes - of course there are many more functions that should be fixed - I just targetted grid.base.js to show you where I was going, and to see what you thought.

Mark

It seems that I do not express myself clear. What I want is that the existing users should not change the existing code and this is definitley done with your script.

I need to do some tests. Also there are other methods whch maybe should be included - in custom module and in user contributed modules.

Thanks again for you work. Will let you know what is my finall decision.

Best Regards

Tony

Yes - my solution doesnt (shouldnt!) break anything - unless the user explicitly asks for the old api to be removed.

I've modified 3.5.2, and put it at http://myosotissp.com/jqGrid-3.5.2x.tgz to show you exactly what Im thinking.

For this, Ive only moved the methods defined in grid.base.js, but I've rewritten all calls to those methods (from anywhere) to use the "new" syntax.

If you use this as a straight replacement for 3.5.2, any existing code should continue to work (mine does!). In addition you can write calls to any method defined in grid.base.js using the new syntax, eg:

                                            var row = grid.jqGrid("getRowData",rowid);

However, if you also set $.jgrid.no_legacy_api=true prior to loading grid.base.js, then /only/ the new syntax is supported (and so none of those names appear in $.fn - which is what Im really after).

Executive summary:

 - no breakage of existing code (unless you want it).

 - new syntax for calling the grid methods (I've started to like this, because it makes it very easy to spot the calls to grid methods in my code). 

 - optionally remove all the clutter from $.fn (requires switching calling code to the new api).

Mark

Thanks for this - Yes I think we can make the grid better. Simple yes, I'm interested, but this should not destroy the old funcionaliy.

Best Regards

Tony

Thanks for the feedback. Sorry to be so slow to respond – I didnt notice your post until now.

I've just looked at the changes, and as you say, its an improvement, but there's still a lot of names added to both $ and $.fn.

I realized my proposed solution – to extend $.fn.jqGrid rather than $.fn – doesnt quite work (after trying it out on one of the methods!), because when you call $(selection).jqGrid.showCol() (for example), showCol gets called, but with the wrong “this” parameter (the jqGrid object, rather than the jQuery object).

It looks like the “standard” way to do this in jQuery UI is to instead do something like $(selection).jqGrid(”showCol”).

I think we could achieve this by following the approach I outlined in my original post, and modifying $.fn.jqGrid to do something like:

if (typeof p == “string”) {

   var fn = $.fn.jqGrid[p];

   if (fn) {

     var args = $.makeArray(arguments).slice(1);

     fn.call(this,args);

  } else {

   // error handling

  }

   return;

}

That way, any of the current $.fn.func could instead be called as $(selection).jqGrid(”func”, args). And as I said before, maintaining backward compatibility is trivial – the old interface would be available unless turned off by a flag.

I would be quite happy to make these changes – if you're interested in taking them? Given the amount of churn in jqGrid (which is good – it means things are improving!) maintaining these changes “externally” doesnt seem like an option.

Mark

First of all I want to Thank you for the invaluable coments. It is a long story…

You are absolutley right. I could not find the right words, but I do not like the methods like $.stringToDoc, $.parse, $.stripHtml .. to appear this way. During the last days before publishing the final release I search a way how this can be done without changing hard the code. Also I have moved these methods to jgrid namespace, not sure if this is the best solution, but….

What I have do additionally is to move all grid methods at end of code and make a fn.extend. This way the loading of jqGrid instace is speeded up (since we do not load every time the methods when we call jqGrid).

Thank you very much again. Will make the code better and better for developers too.

Best Regards

Tony

... at least, what it does... Im a little concerned with how it does it

Basically, Im rather concerned about the namespace pollution. It adds dozens (hundreds?) of names to the $ namespace, and lots more to the $.fn namespace. It even adds a number to the window object.

Many of these names are very ordinary - $.stringToDoc, $.parse, $.stripHtml just to list a few. I'm fairly new to jQuery, so I've not looked at too many other plugins, but if they all do the same, then using them together is likely to be a nightmare.

I realize that the api is now "out there" so you cant just drop it - but I'd like to suggest a possible change to move to a cleaner setup.

If, instead of "$.fn.getGridParam = function...; $.fn.setGridParam = function..." etc, you wrote it as:

var methods = {

    ....

    getGridParam : function...,

    setGridParam : function...

    ....

}

if ($.jgrid.legacy_api) $.fn.extend(methods);

$.extend($.fn.jqGrid,methods);

Then you could have $.jgrid.legacy_api default to true for the next release (or forever, even) - but anyone who wanted to keep a minimal footprint could do so by setting it to false.

Similarly you could create a $.jqGrid which could hold the functions, rather than (or in addition to) attaching them directly to $.

And finally you could move the window.* functions into $.jqGrid.

Net result would be no breakage of existing code, but a much less intrusive plugin (for users who want it) moving forward.

Once again - I really like it, and Im almost certainly going to use it. Id just feel more comfortable if it didnt have such an impact on the namespace...

Mark