[serverside] client parameters: columns (suggestion/question)

ysor123

hallo,

is there a reason, why you dont send all the column information to the server as an array?

Like this:

aColumns[int][bSearchable] : bool
aColumns[int][sSearch] : string
aColumns[int][bSortable] : bool
aColumns[int][iSortCol] : bool
aColumns[int][sSortDir] : string

and so on ...

So you dont have to write serverside logik to combine the data belonging together.

allan

While in some cases you can send an array to the server as an HTTP variable (PHP for example allows you to send "variable_name[]" which will be available as an array called $variable_name) this isn't the case for all server platforms. I'm not aware of anyway to send an array that will work for all possible servers. Any suggestions are very welcome though!

Allan

ysor123

Thanks for answering.

Lets focus on the URI, used to pass a query (basic HTTP-GET)
RFC 2396 says it does not specified the way to use an URI, it specify the syntax and notation. The way to use it depends on the system that parse it. The chars "[" and "]" are no preserved inside the query param name and value - so they can be used. The data passed in the body using HTTP-POST uses the same notation. So there should be no problem on any smart server platform. But your still right, there is a problem - the programming language used serverside.

What PHP does as programm called by server:
it creates a session for the request and initialize some data passed from the server. This includes vars such as _GET and _POST. You can also access the raw URI, request body and URI query which where passed to php. As i know in PHP 5.3 you can even disable this initialization so _POST and _GET is always empty and you can work using the RAW data.

Maybe some other programming language/libraries do not include such an initialization, but you still should have the RAW data, which you can parse a similar way you do it now. I cant imagine a reason why a server should not accept this URI query or DATA inside HTTP body. But maybe i learn something new today :)

If im right, this would be a progressive enhancement. Those who cannot use it wouldnt be damaged, those who can could process it easier.

Noticaeble problem is the lack downward compatibility changing such things for already written code :(

I can imagine there are alot of datatables users using php. PHP is very common in WEB :)