Oleg gridjs - Githubissues

meh-uk commented 9 years ago

Final lot - as before I've just undertaken the technical merge and haven't tested the changes.

flack commented 9 years ago

I just tried merging this locally, but there are multiple errors. At least one of them is in Oleg's original code as well (I just tested with the latest version from his repository to be sure):

Uncaught TypeError: Cannot read property 'length' of undefined jquery.jqGrid.src.js:220
$.extend.clearArray jquery.jqGrid.src.js:220
addXmlData jquery.jqGrid.src.js:1629
$.ajax.$.extend.success jquery.jqGrid.src.js:2349
j jquery-2.1.1.min.js:2
k.fireWith jquery-2.1.1.min.js:2
x jquery-2.1.1.min.js:4
(anonymous function) jquery-2.1.1.min.js:4

@OlegKI: Could you take a look at that? I get it with from grids with datatype: "xml", for example

var post_array = [{"property":"metadata.creator","operator":"=","value":"1ab9f3ba71a5899b8c5e185d59ea50b9"},{"property":"followUp","operator":"<","value":1421794800},{"property":"followUp","operator":">","value":0},{"property":"closed","operator":"=","value":false}];

jQuery("#treegrid").jqGrid({
    scroll: 1,
    url: '/__mfa/org.openpsa.relatedto/journalentry/list/xml/',
    datatype: "xml",
    mtype: "POST",
    height: 150,
    postData: {journal_entry_constraints:post_array},
    colNames:["id",'index_name','Titel','Text','Wiedervorlagedatum','index_object','Verbundenes Objekt'                ],
    colModel:[
        {name:'id',index:'id', hidden:true, key: true },
        {name:'index_name', index: 'index_name', hidden: true},
        {name:'name', index: 'index_name' },
        {name:'description',index: 'description' },
        {name:'remind_date', index: 'remind_date', fixed: true, formatter: 'date', width:140 },
        {name:'index_object', index: 'index_object', sorttype: "text", hidden: true},
        {name:'object', index: 'index_object', width: 120 }
    ],
    rownumbers: false,
    loadonce: true,
    caption: "Journal-Einträge",
    sortname: 'remind_date'
});

flack commented 9 years ago

@meh-uk This line:

https://github.com/meh-uk/grid.js/blob/oleg-gridjs/js/grid.base.js#L2328

should read

type:p.mtype,

(For some reason, gh doesn't let me add line comments to the diff directly...)

flack commented 9 years ago

P.S.: Grouping is also broken. The group header and footer are rendered correctly, but the group rows themselves are missing. This also happens with @OlegKi's original build.

bouks commented 9 years ago

@flack shouldn't it be ts.p.mtype ?

meh-uk commented 9 years ago

No, that's Oleg's change. I'll look at the tp issue tomorrow.

flack commented 9 years ago

@bouks it comes from this commit: https://github.com/OlegKi/jqGrid/commit/868c9c556b83b8b6731ad21bacdfb34f3c13783b#diff-1

meh-uk commented 9 years ago

@OlegKi I'm happy to merge over your fixes from your branch, but ideally if you can fork https://github.com/meh-uk/grid.js/tree/oleg-gridjs and fix there that would be best :)

bouks commented 9 years ago

Too much changes at a time. Why don't you introduce one Oleg's commit at a time, understand it and test it ?

I don't understand why Oleg doesn't fork and merge himself ?

We are coders, not copy-pasters or integrators. That is good for wordpressers. :)

Also, is there an emergency ? Should we code before thinking ?

bouks commented 9 years ago

@OlegKi

Could you please tell us what you are planning about forking or not our repo ?

Do you plan to fork and join us ? Do you plan to have your own project ? Do you prefer stay with Tony or thinking about it ? Do you wait to see how we work before joining ? ...

Sorry, but we need to know since you're much comitting (without forking) in your (Tony's) jqgrid and others try to include themselves your changes.

So, according to your answer, we will do things different ways.

meh-uk commented 9 years ago

@bouks Oleg has committed very little since since it was made clear that his current approach wasn't working. I'm happy to give him as much time to think about it as he needs.

I do agree that now we've caught up we can't continue to merge changes across as we have over the last few days.

meh-uk commented 9 years ago

FWIW I don't have any issues with grouping with the project demos.

flack commented 9 years ago

Strange. What version of jquery are you using in your build & what browser did you use to test. I tried with jquery 2.1.3 and Firefox 35/Mac OS 10.9 and I had this both on the demos and on some of my own grids (with our build and Oleg's)

meh-uk commented 9 years ago

Firefox 34.0.5 on Windows 8.1 with jQuery 2.1.3. But I had fixed the typo.

meh-uk commented 9 years ago

The title feature does seem to be broken though.

flack commented 9 years ago

For reference, here is what it looks like for me:

Current build from grid.js repo (i.e. without this PR):

grouping-working

Current build from Oleg's repo

grouping-broken

meh-uk commented 9 years ago

Merged in changes so this will auto-merge and cherrypicked @OlegKi's grouping fix.

flack commented 9 years ago

@OlegKi I am still getting the error from xml grids, see for example here:

http://demo.openpsa2.org/documents/

OlegKi commented 9 years ago

@flack: Thank you for the demo. I hope that the bug is fixed now. Please refresh jquery.jqGrid.src.js on http://demo.openpsa2.org/jquery.jqGrid.src.js

meh-uk commented 9 years ago

I have cherry-picked this latest commit over.

flack commented 9 years ago

@OlegKi Looks good! I still have the problem we talked about last week (wrong row ids in treegrid with xml data):

http://demo.openpsa2.org/documents/

You've mentioned that I can work around it by changing my setup code, but I was wondering: do you plan on fixing it at some point? If not, I might take a look myself (but not before next week, most likely)

flack commented 9 years ago

One other thing: I have a grid with scroll: 1 and rowNum: 6. Until now, it has always loaded 6 rows per request, but now it loads 1000. Is that a bug or some sort of new feature?

Config looks like this:

$("#grid").jqGrid({
    colNames: ["id","index_number","Invoice","Customer","Customer contact","Due date","index_sum","Amount","Paid date"],
    colModel: [
        {name: "id", index: "id", hidden:true, key:true},
        {name: "index_number", index: "index_number", sorttype: "string", hidden: true},
        {name: "number", index: "index_number", width: 80, align: "center", fixed: true, classes: "title"},
        {name: "customer", index: "customer", sortable: false, classes: "ui-ellipsis"},
        {name: "contact", index: "contact", sortable: false, classes: "ui-ellipsis"},
        {name: "due", index: "due", width: 80, fixed: true, align: "center", formatter: "date"},
        {name: "index_sum", index: "index_sum", sorttype: "number", hidden: true},
        {name: "sum", index: "index_sum", width: 80, fixed: true, align: "right"},
        {name: "paid", index: "paid", width: 80, align: "center", formatter: "date"}
    ],
    datatype: "json",
    sortname: "paid",
    sortorder: "desc",
    scroll: 1,
    rowNum: 6,
    height: 120,
    viewrecords: true,
    url: "/invoices/list/json/paid/",
    caption: "Recently paid invoices",
    footerrow: true,
    loadComplete: calculate_total
});

flack commented 9 years ago

one more JS error:

http://demo.openpsa2.org/invoices/invoice/items/0181b6ff4caa556f7c974185d159722f/

if you click anywhere in the row, you get:

TypeError: rowid is null
.getGridRowById(rowid=null)jquery.....src.js (Zeile 3494)
$.fn.jqGrid(pin="getGridRowById")jquery.....src.js (Zeile 1047)
.setSelection/<()jquery.....src.js (Zeile 3559)
.each(a=Object[table#invoice_items.ui-jqgrid-btable], b=function(), c=undefined)jquery-....min.js (Zeile 2)
n.prototype.each(a=function(), b=undefined)jquery-....min.js (Zeile 2)
.setSelection(selection="1797", onsr=true, e=Object { originalEvent=Event click, type="click", timeStamp=22744178, mehr...})jquery.....src.js (Zeile 3529)
$.fn.jqGrid(pin="setSelection")jquery.....src.js (Zeile 1047)
$.fn.jqGrid/</<(e=Object { originalEvent=Event click, type="click", timeStamp=22744178, mehr...})jquery.....src.js (Zeile 3232)
n.event.dispatch(a=Object { originalEvent=Event click, type="click", timeStamp=22744178, mehr...})jquery-....min.js (Zeile 3)
n.event.add/r.handle(b=click clientX=664, clientY=139)jquery-....min.js (Zeile 3)

flack commented 9 years ago

P.S.: Noticed that I get the error on all grids, not just the one linked. It happens every time you click on a row

meh-uk commented 9 years ago

Whose "fault" is that? Mine or Oleg's?

flack commented 9 years ago

I'm testing with Oleg's last build

OlegKi commented 9 years ago

I've fixed the bug too: see the last commit

flack commented 9 years ago

Ok, JS error is gone now. Still have the problem with treegrid (but that is already in Tony's 4.7.0 release) and the wrong row number in request for the scroll: 1 grid. Will test the PR version later today

OlegKi commented 9 years ago

@flack : could you post me URL to the demo with scroll: 1 problem or any other with the bug? It would very simplify the fixing.

About the problem with the usage of key:true in XML input having xmlReader in repeateitems: true format (it's default setting), I will fix it very soon. I wrote you that you can use xmlReader: { id: 0 } (or xmlReader: { id: "0" }) and remove key: true from the first item of colModel as the workaround. The value of id should be 0-based index of the column where you had key:true before.

meh-uk commented 9 years ago

That's now in this pull.

flack commented 9 years ago

@OlegKI: Here you go:

http://demo.openpsa2.org/invoices/

It's the third grid (the one with the green heading)

OlegKi commented 9 years ago

Thank you for the demo. I fixed some clear bugs in the code responsible for virtual scrolling. Could you refresh jquery.jqGrid.src.js once more and I retry the test of http://demo.openpsa2.org/invoices/?

meh-uk commented 9 years ago

@OlegKi I really don't know how to be any less subtle about this. Can you please stop making changes on your outdated branch that is very difficult for us to merge in.

Practically every commit conflicts - it is a massive pain to merge and it is impossible for anyone else to do anything significant as the position will become even worse.

It isn't going to work for us going forward for you to write your code on your own branch and assume a magical fairy will merge the code across.

flack commented 9 years ago

@OlegKi I've refreshed now as requested. It works fine under normal condition, but I managed to get a JS nonetheless. To reproduce:

Maximize the grid (looking glass icon on the caption)
Scroll to the bottom until all rows are loaded
Click on the maximize icon again to return grid to normal size, then the following error appears:

ReferenceError: table is not defined
$.fn.jqGrid/</grid.populateVisible()jquery.....src.js (Zeile 1387)
$.fn.jqGrid/</grid.scrollGrid/gridSelf.timer<()jquery.....src.js (Zeile 1407)

The maximizer is my own custom code, but the error comes from jqGrid, and it was working fine before, so this looks like a regression. You can find the maximizer code here:

https://github.com/flack/openpsa/blob/master/static/org.openpsa.widgets/jqGrid.custom.js#L97

It may have something to do with the fact that the grid gets detached from DOM during maximize/unmaximize, but I haven't debugged it yet.

Oh, and for the record: I agree with @meh-uk: The current modus operandi is not sustainable. We need to agree on one upstream, because all this merging produces lots of unecessary work, not to mention the potential to introdcue lots of new bugs

bouks commented 9 years ago

@meh-uk you can't blame Oleg because you choose to import and merge. He didn't do it. If he wants to make changes to his tony's fork, it's his right.

@OlegKi Could you please answer what i asked you here :

https://github.com/openpsa/grid.js/pull/60#issuecomment-70013852

flack commented 9 years ago

@bouks: It's not about blaming anyone, it is about having the best jqGrid version possible. And for this, all contributors should work together IMHO

meh-uk commented 9 years ago

I'm quite happy to have merged in Oleg's previous changes to show good faith and to make it so he could fork our code without losing too many of the changes he'd already done. Now that we've got both repositories in line we are in a position for Oleg to fork our code without losing any changes, so now he needs to make a decision.

I hope he decides to join us but if he doesn't fork our code then I guess we will have to assume he is doing his own thing independently.

bouks commented 9 years ago

@flack Sure. We need know answers from Oleg.

meh-uk commented 9 years ago

Seriously, I slightly get the impression Oleg hasn't done a lot of stuff with git and hasn't merged branches etc in a public project before, and so he doesn't understand why this is such a big problem.

That isn't a problem at all, but it is something that needs resolving.

flack commented 9 years ago

Oleg proposed a Skype call. Maybe we should do that instead of writing stuff here in the heat of the moment (that will be visible forever...)

flack commented 9 years ago

I've tested merged this locally now, added some more of Oleg's commits:

I've also fixed the JS warning I mentioned above:

https://github.com/openpsa/grid.js/commit/127477d21e315332b3215eec4f64143115596ca9

Since the changes are pretty extensive, I strongly suspect there will be more errors that are yet undiscovered. They just always crop up during large refactorings like that. It might be a good idea to have some stabilization period, especially since we should do a first release in the near future.

OlegKi commented 9 years ago

Hi @bouks , @flack , @meh-uk

I want to answer on some common questions asked frequently last time: what it about my plans and what is my goal.

I want to provide bug fixes, new features, common code improvements, new better documentation and a lot of working demos, which demonstrate best practice of the usage of jqGrid in different standard scenario. Therefore, I want to continue to develop free version of jqGrid. I define it as my goal. Everything, which bring me (or us) closer to the goal, is welcome.

I am opened to every cooperation which speed up creating new improved version of jqGrid. I find the most discussions with you very helpful. I changed the structure of new jqGrid options and some names based on the discussions for example. I think that the new system for building of jqGrid, which you made is very good, the downloader of custom build of jqGrid or the construct of new documentation is very good too.

Our cooperation can be mostly productive if you can do some parts of work where you have more experience as I have. For example I know very good jqGrid code. I know JavaScript and jQuery good too, but I know CSS not so good, especially the specific of old web browsers. If somebody would analyse and improve jqGrid CSS, it would be very good.

Another example. You made good downloader of custom build of jqGrid. There are some methods of grid.custom.js, which will be very frequently used and other, which are used seldom. The module grid.formedit.js contains searchGrid which should be better be grouped with grid.filter.js. The module grid.formedit.js contains navGrid, navButtonAdd and navSeparatorAdd which could be moved in new grid.nav.js module. Currently if one want to add his own custom button one have to include full form editing module. If one want to use inlineNav for inline editing, then one need to add full form editing module because of navGrid which need be called with skipping of all form editing buttons. I can continue...

One can examine suggestions from https://github.com/tonytomov/jqGrid/pull/657 or makes his own investigation and to formulate the bast way for jqGrid to implement AMD support. One can share his knowledge, create the demos and finally makes the corresponding modifications in the code of jqGrid.

Every new version need be tested. If nobody knows good enough any unit test system then one can create some demos, which one could use to validate regularly the last changes in jqGrid. One can make some investigation about performance. One can create some tests on http://jsperf.com/ to verify, whether the tested modification of the code really have sense.

The practical example. @flack wrote suggestions about colgroup to improve the performance of hiding the grid having many columns and many rows. I have absolutely the same idea some time before, but I couldn't find the solution in the way. I have another implementation idea, which need be validated. I want to use the trick described in the post. One can temporary remove grid (gview or the whole gbox) from the DOM (from the page). One need just get the parent of the grid (I mean better gview of gbox) and to save nextSibling of it. Then one can call parentNode.removeChild to remove the grid. After that one have disconnected grid and one can make modifications like assigning display:none (or removing it) from the grid. No reflow will take place. I hope that one can dramatically improve the performance of showCol, hideCol in the way. If the tests shows performance improvement, then one can examine the code of jqGrid where the changes of multiple elements can be made on disconnected grid. One can include the same trick on the places too.

If somebody would say that I suggest you some work, which I don't want to do myself it would be incorrect. If nobody would decide to write the test or unit tests, the documentation or performance tests I would do the work myself. I'm sure that without meh-uk or some other, which first language is English, the documentation could be not good enough. So without to know meh-uk I'm sure that the part he can better as I could.

The most advantage of cooperation is: one can create new version of jqGrid much sooner in the team as I or somebody from you could do alone. Moreover the version could be much better tested as every jqGrid version published before.

By the way I wrote @flack that jquery.jqGrid.min.js produced with Closure Compiler is smaller, but I made later another tests with respect of gzipped utility and could see that the Compressed size of gzipped jquery.jqGrid.min.js created by UglifyJs is still smaller. It would be good if somebody make more detailed investigation of the subject.

Another TODO, which is important and which is not a "dirty work": one need to collect bugs, suggestions of new features, organize there, one need to choose the best behavior, which need be implemented. Writing of product specifications is clear no "dirty work". At the beginning I could implement the changes in JavaScript code better as other, but I can comment the parts of code and explain you, which parts are bad and why. After that you can makes the modifications of the parts.

In any way, I want to make many changes in jqGrid code and to share the results with all other. I want to prepare small documentation about the internal structure of jqGrid (all internal divs, tables and the structure like the property grid). I want that more people could understand the code.

I don't see any sense in merging the changes from one github repository to another. It takes just time. It some merging not works it would be enough to make simplest copy of files and to commit the changes with the comment which have the URL to another github repository. One will have identical results from the point of view the main goal, which I formulated at the beginning.

I have to mention one more problem in our cooperation: How long we known us? Not so long time. What is the goal of every from you? Everybody knows that the success of the work in the team depend on many factors. Could we be a good team? It's still unclear for me. So I just make what I can do from my side: I'll continue changing of jqGrid code. I have to inform you, that it could be that I will have to make a pause in the development because of projects for my existing customer. I have to earn money for my family. :-) I think it's clear too. So I'm trying to use the pause between projects now to make something (I mean improving jqGrid) for free for other people.

I hope that I impressed my clear enough.

Best wishes Oleg P.S. Sorry, that I wrote so long text.

OlegKi commented 9 years ago

@flack Sorry, that I still didn't fixed the bug in addXmlData, which you reported me before. The main reason was: I found the code of addXmlData not so good and I would like to make many changes in it. After writing the previous comment I though: it's better to write first quick and dirty fix of the bug and to rewrite addXmlData somewhere later. So I debugged the demo one more time and have wrote the small bug fix. I think it will work.

Best regards Oleg

bouks commented 9 years ago

@OlegKi

I don't understand. You don't want to merge in a single project ? And do copy/paste ? That's not what i imagine if i work with people in a project.

You wrote : "If somebody would say that I suggest you some work, which I don't want to do myself it would be incorrect... you will do myself". It still sounds like : "if you don't help me, i'll do it on my own". And you wrote that we have to implement this or that... That's again not my idea of a team. Everybody could suggest things and code and decisions can be made a collegial way (or not for little things :) ). Also, for me, there is no dirty work. Doing what we know is very well, experiment new things is better, it's the only way to improve ourselves (individually and as a team).

What i understand about what you wrote is you want to take the lead but keeping separate projects. This is weird.

We all have skills, differents and/or sames. That's true that you're involved in jqgrid before us. But you can't say : "I could implement the changes in JavaScript code better as other". You just can say : "i could implement faster".

Sure you can see bad parts, i've seen also. In software design particularly. Maybe meh-uk and flack have seen other things. So i think you can't just say : "this is bad, we are doing like that, i tell you what to do".

I've done some little things here, but i've done some other things that i didn't include in "my" jqgrid because Tony didn't merge some PR that was merged here (for a year and a half!). He also didn't reject it. So i had to keep separate "my functionnality" to use jqgrid and follow the updates.

About your questioning :

How long we known us? We don't have to know us for long to work together. When you integrate a team in a job, you know no-one. We just work for a project. Here it's a free one. Free mean open-sourced, free of charge AND free of joining or quitting. If we don't work well together, we can split. But in the meantime, we would have done work and everybody takes a win of that.

Could we be a good team? I'm not asking myself this type of question. I live in the present, i don't see nor imagine the future. Something happens that making us join together on a-or-some purposes, so i just do things with others, and that's the only thing that matter.

But not integrate the team (by keeping separate projects) is definitely not the way. Also that it is not : "So I just make what I can do from my side: I'll continue changing of jqGrid code."

Best.

flack commented 9 years ago

@OlegKi: I can agree with most of what you said, but here's my problem:

you are working on the repo forked from Tony. You can't push your changes and you can't pull changes from Tony because of the incompatible licence. So in reality, your repo is completely isolated
the rest of us are working on the grid.js repo. For now, we tried to do only minimal changes to the Javascript files to be able to merge your changes. This means that we could not merge some of our own work (for example https://github.com/openpsa/grid.js/pull/26), which is really frustrating.
if you continue to commit your changes to a repo forked from Tony's, this means that you are forcing us to decide between not changing the Javascript ourselves (and also not accepting pull requests from anyone) or ignoring all your changes. Copy and paste is NOT an option, because it will never work over the long term.

The solution is really simple: Just fork the grid.js repo and do your changes there. Your workflow would be exactly the same as it is now, except that once you are finished with one set of changes, you can submit a pull request. Then, everyone has a chance to review and test them. This means that your code will get better, because more people will always find more problems (see for example the issues we've found during the most recent merge).

It also means that there is one canonical repository for users to file bugs against. Because from the users point of view, the current situation is completely confusing. Just imagine that six months from now, somebody posts a jqGrid question to stackoverflow, and you have to ask "which jqGrid do you use, grid.js, Guriddo, or Oleg's?"

I think we can all agree that you have the most jqGrid knowledge of all of us. But that doesn't help if you make collaboration difficult without any good reason. So can't we just solve this organizational problem and get on with what we really want to do?

smartcorestudio commented 9 years ago

@flack I'm not Oleg:), I'm just a user of jqGrid. But I "+1" your comment. I think it will be better if we'll have 2 "former jqGrids" than 3

meh-uk commented 9 years ago

For me personally being able to get pull requests accepted is very important when using an open source project.

flack commented 9 years ago

@OlegKi Case in point: Just in the last twelve hours, you have changed almost 2300 lines:

https://github.com/OlegKi/jqGrid/compare/OlegKi:5cc3a30d51b3ef64817c61951826170208675109...eca2bd59942f36cfc0a25e666e757e3bd19d9706

You can't really expect that one of us copies over all that by hand, and makes sure that they work with the other changes that we have each and every day

smartcorestudio commented 9 years ago

@OlegKi Sorry if it's not my business, but it's interesting for me what is the principial difference between your fork and this grid.js? Maybe you just want to be the only man who can accept other's pull requests, like Tony was in original jqGrid? I can't see any other principial differences between two forks now. If so, what do other guys think about it? Is it acceptable or not?

meh-uk commented 9 years ago

The primary difference between the two is that we've accepted all the pull requests from other people, plus we've switched the build system over to grunt and the css over to less as they are easier to use and more maintainable. Plus more people can accept pull requests which means changes are more likely to be accepted. @OlegKi's fork only contains his changes.

I suppose the key question for @OlegKi is whether you are interested in managing the project, or whether you'd prefer to spend your time programming, my impression is that you prefer programming to management, which is totally fine, but then that means its probably best for your repository not to be the primary one.

OlegKi commented 9 years ago

@flack: You are write that my current state of jqGrid fork is very far from Tony's jqGrid. It have sense to rename the fork and make it independent from https://github.com/tonytomov/jqGrid like you did it before.

I have no problem to work on common repository, but, as I wrote before, I know you and other too short time. Your current fork is under https://github.com/openpsa and OpenPSA is your product or at least the name of Open Source product which exist since 2004. It looks like the new jqGrid project is a subproject of OpenPSA. It's the main reason why I'm not hurry to move my activity to OpenPSA grid. I have no problems to give all from you the write access to my repository. I would agree if we create common github repository on the "neutral" place.

One more reason follows from unclear rules of the our community. For example, your fork contains two main changes which making conflict with my changes. It's changing of the structure of filter toolbar, hidding some filter toolbar components, which are really unneeded in combination with other options and the implementation of detection of datatype. The changes are suggested by @bouks . The problem is that I have another opinion about the changes. I full agree with hidding some filter toolbar components, but I don't like the implementation. I wrote that one can implement the same behavior of the filter toolbar with minimal changes in the code. I made the changes in my repository. Which advantage to change internal structure of the filter toolbar? I don't know any benefit from the point of view of the final results. The problem is that such changes could break some existing customization code which somebody already implemented in projects which uses jqGrid. So I would be change the internal HTML structure of jqGrid only if one would have really large improvements, which I don't see here.

Another example. I really don't see any advantage from changing static CSS to LESS. The LESS files have no logic. So I see no advantages. Probably somebody can point to someone?

The autodetection of datatype seems a good feature at the first point of view, but ... The first problem: There are some existing backend products which makes autodetection of the format based on dataType used in the Ajax request. For example the WebServices of Microsoft (I mean .ASMX) return XML or JSON depend on it. I'm abrade that such systems will return XML in the case. It you would open the URL in web browser then you would see XML instead of JSON. So such autodetection could change the format returned from the server. jqGrid callbacks, custom formatters, cellattr and rowattr just ptrovide the response as the parameter of the callback. So it makes break the existing code. The code of loadComplete: function (data) { ... var rows = data.rows; ...} will not more work because data.rows will be wrong for XML response.

Moreover, what is real use case of the usage of autodetection? One have to know exact format or returned data to create the grid. If one uses repeatitems: false format then the name property (or jsonmap) should exactly corresponds to the input data. To process XML response one have to write frequently another code. So if somebody use url parameter he have to know the format of data. He knows the type of returned data. So why one should not make datatype mandatory for the remote data? Why one should skip the option. So I don't understand the real case of the usage of autodetection of the format of the server response. I see more disadvantages in the implementation of the feature as advantages.

If we work in the team it could be different opinions about the same subject. The best way to discuss advantages and disadvantages of suggested changes before the implementation. I don't want to push my opinion, but what can we do if we could not find a compromise? It's unclear for me for the current absolutely opened community.

I hope that you understand me more now.

@bouks : You wrote

you can't say : "I could implement the changes in JavaScript code better as other". You just can say : "i could implement faster".

I don't wrote that I know JavaScript better as you. I wrote only that I know currently jqGrid better as you. I suggested that I can share my knowledge with you all.

And you wrote that we have to implement this or that... That's again not my idea of a team. Everybody could suggest things and code and decisions can be made a collegial way (or not for little things :) ).

On the contrary. I wrote that currently I know jqGrid internals better. So I suggested that you collect the features, we discuss in which way (which options for example) would be better for the users and after that i suggested that I implements your requirements. So you say me what to do and I decide (only at the current state) how to implement the feature and to write the implementation myself. Moreover I wrote in which areas I fill me not so good. CSS for example. So I would prefer if somebody who knows the subject better as I to make the implementation. I would just test the results and to say my opinion.

One more common remark with communication with bouks. It seems to me that you makes all critic in your address to personally. If I see that the code can't work in the current form and I ask you whether you tested it, you don't answer me. On the second time you makes the changes on which I point you and you answers that you do have tested all. I don't remind that you ever said "thanks" if one pointed to a problem in your code. I think that everybody from the team should try to be be polite to other and to take easy a critic in his direction. We should try to be objective. Isn't so? Everybody makes errors. I posted bugs in my code too, but I was happy if somebody point to the bug. At least I try to be objective.

@meh-uk I wrote above the reason why I don't make my changes on OpenPSA grid. I can provide you write access to my repository or to move my repository and merge it manually with youth on new neutral place.

@smartcorestudio I tried to describe above "the principal difference between my fork and this grid.js".

About many changes in the code: I wrote that it was not in my plans originally, but I make one small test and find out very simple method to transform existing code of jqGrid with no side effects (but many changes) which *reduce the size of jquery.jqGrid.min.js. I suggested to make Skype conference. I could explain exactly what I do. It's very simple, but describing of all here can take too many place. Moreover you can have your questions which I could answer directly. We could share the work. Somebody from you can get one jqGrid module and to make the same modifications. I would place the changes immediately in my repository (on in our common repository).

Best wishes. Oleg

openpsa / jsgrid

Oleg gridjs #60