srchulo / datatables Goto Github PK

Is there a reason why the module uses AutoLoader? As far as I can see, all methods are preloaded (plz correct me if I'm wrong).

Could you maybe set up Travis CI for this repository? It's really simple (just create an account and add a .travis.yml file) and it gives you automated tests for pull requests. Cf. https://travis-ci.org

Similar to the DataTables editor library, DataTables could offer a generic hook where arbitrary post-processing could be done.

Also, maybe add to the docs more clearly how patterns work and that it is result post-processing. Maybe add a sample script (have one) or a test showing the feature.

Per #33 I think it would be prudent to provide a dockerfile to containerize the app and allow for smoother testing and deployment. See https://docs.travis-ci.com/user/docker/ for reference.

Could you please release a new version of DataTables to CPAN to publish the changes?

I would be happy to do co-maint for the module on CPAN if you like, so I could push new releases, too.

Could you please release a new version of DataTables to CPAN to publish the changes?

Currenty, a JSON response looks like this:

{
	"aaData":[
		[25,"Misc","NetFront 3.4","Embedded devices","-","A"]
	],
	"recordsFiltered":1,
	"recordsTotal":57,
	"draw":27
}

The fields are represented by array index. Column 0 holds the ID with value 25 in the example above.
It's not yet possible to get a mnemonic answer like this:

{
	"data": [
		{
			"id": 25,
			"engine": "Tiger",
			"browser": "Nixon",
			"platform": "System Architect",
			"version": "[email protected]",
			"grade": "Edinburgh"
		}
	],
	"recordsFiltered":1,
	"recordsTotal":57,
	"draw":27
}

The module uses index_cols to count the number of results (not sure however if it is done correctly).
Why did you use the index_cols? I ask because SELECT COUNT(*) does the same without the knowledge about index_cols.

Is it DataTables 1.9 or lower? The POD doesn't state it.

I would like to add a possibility to re-use an existing query. Mainly, to make testing easier. This way, one can simply provide a query object with a param method, that will be accessed by the module.

There is multiple approaches:

• add a param to new
• add a new attribute, like dbh
• create an accessor method similar to cgiapp_get_query of CGI::Application that can be overridden

Not sure if it could be useful for anything other than testing.

Would it be ok to add this feature and which possibility do you prefer?

It is possible to define a website along with the Github repository name.
Could you please add a link to https://metacpan.org/pod/DataTables as website to make it easier for noobs to find the module's documentation?

In the current code, mysql is hardcoded. Why not just have the user provide a database handle and use a library like SQL::Abstract to build the queries?
This way, the module can be used with (for example) SQLite as well.
If it's OK for you, I can submit a pull request.

As CGI is only used to access query parameters, a more lightweight module like CGI::Simple would be sufficient, too.
In addition, CGI has been removed from the core, so it doesn't matter if CGI or CGI::Simple has to be installed as dependency.
If you like the idea, I can submit a pull request.

Using DataTables 1.10, I get an error "TypeError: data is undefined" when a search in the table data returns an empty result.
For example, response data looks like this: {"recordsTotal":57,"recordsFiltered":0,"aaData":"","draw":19}

Note that I assume that aaData should be data anyways.