Post instead of get about flexigrid

[daxxog]

You can already do this just set the method property. POST is just the default value but you can change it.

$("#flex1").flexigrid({
    url: 'post2.php',
    method: 'GET',
    dataType: 'json',
    colModel : [
        {display: 'ISO', name : 'iso', width : 40, sortable : true, align: 'center'},
        {display: 'Name', name : 'name', width : 180, sortable : true, align: 'left'},
        {display: 'Printable Name', name : 'printable_name', width : 120, sortable : true, align: 'left'},
        {display: 'ISO3', name : 'iso3', width : 130, sortable : true, align: 'left', hide: true},
        {display: 'Number Code', name : 'numcode', width : 80, sortable : true, align: 'right'}
        ],
    buttons : [
        {name: 'Add', bclass: 'add', onpress : test},
        {name: 'Delete', bclass: 'delete', onpress : test},
        {separator: true}
        ],
    searchitems : [
        {display: 'ISO', name : 'iso'},
        {display: 'Name', name : 'name', isdefault: true}
        ],
    sortname: "iso",
    sortorder: "asc",
    usepager: true,
    title: 'Countries',
    useRp: true,
    rp: 15,
    showTableToggleBtn: true,
    width: 700,
    height: 200
});   

[gsonnenf]

I did change it already. What I'm saying is there are standard conventions for REST, and using GET to get items is one of them. It should be the default. If you want to be some kind of rebel or cowboy and use POST as your 'smart default' instead of GET, you are on your own, the rest of world uses GET for this type of thing.

[paulopmx]

Well, Flexigrid isn't just meant for REST. It's design to be flexible and
simple to use by anyone, and not to force anyone on what backend standards
to use.

If you are unhappy with that principle you can simply fork the repository.

Paulo P. Marinas
Chief Technology Officer

On Sat, Dec 8, 2012 at 7:29 AM, gsonnenf [email protected] wrote:

I did change it already. What I'm saying is there are standard conventions
for REST, and using GET to get items is one of them. It should be the
default. If you want to be some kind of rebel or cowboy and use POST
instead of GET, you are on your own, the rest of world uses GET for this
type of thing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-11150840.

[gsonnenf]

The behavior of GET and POST isn't just for rest. Please see the definition of the HTTP protocol: http://tools.ietf.org/html/rfc1945#section-8.1

Both GET and POST can of course be used, but GET is intended for this use. If you think changing a the smart default fetch method, from POST to the industry default of GET, in anyway compromises principles of 'flexibility' and 'usability' you are making things up.

The only advantage I can see gained by leaving the default as POST would be to maintain backward compatibility. Changing it to GET, the industry standard as defined by standards committees and most documentation, best promotes simplicity and ease of use, and is neutral in terms of flexibility.

You are welcome to keep replying to this thread and making suggestions I don't agree with.

[paulopmx]

We are not imposing our beliefs in you so don't impose yours on us.

This is an open source world. Every one is entitled.

Claiming your belief is better or correct than others just makes you a delusional bully.

You are welcoming me to speak but disclaim its all but worthless.

Then what are you doing here. Go to a different plugin.

As I said in my previous you are free to fork and promote your own copy.

On Dec 9, 2012, at 8:44 AM, gsonnenf [email protected] wrote:

The behavior of GET and POST isn't just for rest. Please see the definition of the HTTP protocol: http://tools.ietf.org/html/rfc1945#section-8.1

Both GET and POST can of course be used, but GET is intended for this use. If you think changing a the smart default fetch method, from POST to the industry default of GET, in anyway compromises principles of 'flexibility' and 'usability' you are making things up.

The only advantage I can see gained by leaving the default as POST would be to maintain backward compatibility. Changing it to GET, the industry standard as defined by standards committees and most documentation, best promotes simplicity and ease of use, and is neutral in terms of flexibility.

You are welcome to keep replying to this thread and making suggestions I don't agree with.

—
Reply to this email directly or view it on GitHub.

[gsonnenf]

Paulo, I think you should understand that if you open source a project and try to build a community around it, you will sometimes be subjected to criticism, often times may be constructive.

Repeatedly telling me I'm not welcome here while calling me a "delusional bully" because I made a rational argument about standard coding practices is passive agressive and hypocritical. I'm not sure what you hope to accomplish with your plugin, but good luck with it. I'm sure you will still have a user base even if your code deviates from typical usage.

[ecaron]

@gsonnenf The saying about arguing online has been said frequently enough, so I won't restate it.

This thread had a lot more passion in it than was necessary, which is disappointing because there is obviously a lot of intelligence in this thread.

Can we all calm down a bit and let this thread end? Paulo's point is well stated that if you're so disappointed with the Flexigrid community's behaviour, you are welcome to fork and start your own.

Personally I am pleased with the POST being used instead of GET because I've encountered far too many misconfigured squid servers, and using POST is an unfortunate-though-super-effective work-around for the internet we're stuck with rather than the theoretical one we all dream about.

[paulopmx]

@gsonnenf I think you should know that stating:

"You are welcome to keep replying to this thread and making suggestions I don't agree with."

Is not a "rational argument."

It's not even a conversation. You talked and covered your ears at the same time.

If you had asked us why we do one thing one way and not the other (possibly better) way, instead of just calling our way wrong, that would be true example of constructive criticism (opinions that usually involve both positive and negative comments, in a friendly manner rather than an oppositional one) would be like. You did the opposite.

And as a correction, I have never said you are not welcome here. I've only repeatedly stated that as an open source project, you have the option of forking our work. But if you don't want to fork we don't have an option for you here, but you may have an option in another project.

If you have an open source project and trying to build a community around it, everybody is welcome to contribute, criticize, and fork, but that doesn't mean you can accept all changes that everybody wants all the time. You have to maintain a single vision for the project, otherwise, you end up with a project, that's going everywhere and going nowhere.

I apologize to implying that you are a "delusional bully." But I can't stand people who likes their opinion being heard, but at the same time don't want to listen.

As a contributor, you should understand, you will sometimes be subjected to rejection of your contribution or opinion, even if they are often times may be constructive. But that doesn't mean you shouldn't play nice and be respectful of other people's work.