@OzanKurt the PR looks good, I have the same idea on my todo list. Glad you initiated this.

Some points:

Custom JS functions:
The code now allows jQuery and JS codes to be printed as literal functions.

• Can you please put this function to a separate PR so that it can be merged immediately?

Just like the render method does.

• Maybe we can refactor this code on the abstract class to avoid duplication and we have a single source of truth when processing the ajax request?

• Does this work onpost request?

• Please add the missing doc blocks.

Will to test this as soon as I can. Thanks!

Can you please put this function to a separate PR so that it can be merged immediately?

I am not sure how I can split those now thou. :(

Maybe we can refactor this code on the abstract class to avoid duplication and we have a single source of truth when processing the ajax request?

Yes, this should be done. I will be working about that anyways since I am currently building a "base starter template project" for my company, everything has to be perfect.

Does this work on post request?

We can change where it works by editing theHtmlServiceProvider, where we push the middleware to the kernel. The main check I did there was$request->isAjax() || $request->wantsJson().

Please add the missing doc blocks.

Thanks a thing I should also do 👍

I don't know how to make two different pull requests at once, so I reverted theisJavascriptFunction part from this one. Will make an another one hopefully once we merge this.

I added information about what I did to the commit message:86cc8ad

I just released your snippet for the js function. Thanks!

On the other hand, do you think it's ok to pass the FQCN on the query string? Having a look on my notes, this is how I planned to implement this.

• Create a common end point that will handle all dataTables requests. Or in this PR, the middleware will handle all the request.

• Create a dataTables mapping with the concept of Laravel's event & listener.
  If we will use middleware, then maybe we can create a base middleware that the user can extend and then define all the mapping? Something like:

namespaceApp\Http\Middleware;useClosure;class DataTablesMiddlewareextends SmartDataTableMiddleware{protected$dataTables = ['users' =>'App\DataTables\UsersDataTable','posts' =>'App\DataTables\PostsDataTable',    ];}

This way, we only need to includesmartDataTable=users on the query string and making our code a bit secure and not exposing our codebase structure?

Let me know what you think? Thanks!

I also thought about the code security as you did, for me this was the fastest solution I was able to come up with.

That$dataTables mapping seems fine, but then we will need to declare the mapping elsewhere again.
Plus, the keys might be confusing if someone uses both custom id and "smart mapping key". Let me exemplify what i mean by that.

I coded a project for British Taekwondo Federation, where I needed to display a dataTable to 4 different user roles differently. Like:Admin\UsersDataTable,Instructor\UsersDataTable,Member\UsersDataTable. So the "html id" of the dataTable will beusersDataTable all the time but smart mapping will be something like:

protected$dataTables = ['adminUsers' =>'App\DataTables\Admin\UsersDataTable','instructorUsers' =>'App\DataTables\Instructor\UsersDataTable',// And so on...    ];

The problem with this is that the classes I am using extent a base class. Where I can simply mark them as:

protected$smartDataTables =true;

In this case I would need to add$smartDataTables attribute individually and need to keep track of them being unique.

protected$smartDataTables ='adminUsers';

But still seams reasonable.

Finally, I personally believe that FQCN won't harm us in terms of security. The max. I would do is to remove the "Application Namespace" from it, so it looks like:DataTables\Admin\UsersDatatable.

Since Laravel has the command to change thisApp\\ namespace. (php artisan app:name) Companies would still keep the FQCN private.

We can also use a tiny en/decryption algorithm to secure the class names.

https://nazmulahsan.me/simple-two-way-function-encrypt-decrypt-string/

Hello,

i think using encryption is a bad thing for readability, perhaps an additionnal sign key would be suitable :

Hash::make($this->smartDataTables);

something like this, and check the hash in the request maybe.

It will be used with datatable buttons ?
perhaps we can use dataTableVariable property in this case i don't know.

Hash::make($this->smartDataTables); will create a looooooooooooooong string, therefore will make the query string even dirtier.

It depends on the used algorithm, with Bcrypt it's 60 characters, it's a bit long perhaps, but some FQCN can be as long as the hash. I think using only the base class name could be enough, but it can cause conflict with other datatables of same name, so i don't know.

In my code, i have multiple datatables on the same page, with same url, and i'm using the dataTableVariable property of service datatable, but it is set by hand in the child class so not a real problem, and im usinglcfirst(class_basename($dataTable)); by default when dataTableVariable isn't set.

We need a reversible encryption method to decrypt the class name after the request thou.

re: FQCN, I think what@yajrasuggested earlier about a mapping list in the middleware is what this package should offer out of the box. Then if someone wants to add their own changes, either to expose their own FQCN or to Hash:: it, or whatever, they can extend this package's middleware to do their own thing.
That way this SmartDataTables feature can be released, and others can battle-test other ideas in the wild and offer alternate proposals via PR.

Sorry was not able to review and this is already outdated. Closing, thanks!