|
Warning
|
This package is not production ready yet. You can still use https://github.com/Chumper/Datatable but be aware that it will not receive any new updates. |
This is the development repository for the refactor of Openskill/Datatable for Laravel 5 and 4. In this repository we are developing and discussing the structure of the new version.
See issue #2 in the bug tracker for an up to date list of current issues.
Here I want to discuss the proposed usage of the API. In general I would prefer to concentrate on a single route functionality so we can transfer all server side settings into the view without declaring it twice.
Nevertheless I would also offer the possibility for two routes, which will require more configuration from the developer.
$datatable = Datatable::make(new EloquentModelProvider(User::class))
->column('name')
->build
return view("template", $datatable)And in the view
{{
$datatable->table();
$datatable->script();
// or
$datatable->html();
}}So all configurations from the server side are passed to the client side without the need to declare it twice.
{{
$table = Datatable::view()
->column("Name", "Email")
->url(URL::to('auth/users/table'))
}}
{{
$table->body() //(1)
$table->script() //(2)
}}
{{
$table = Datatable::view()
->column("Name", "Email")
->url(URL::to('auth/users/table'))
->option(...)
->html()
}}-
Render the html table
-
Render the javascript
Maybe we need to drop the client side of the plugin if it is too much work, but I always liked the easy setup with the tables.
Datatable::make($provider)
->...I could imagine different providers, like CollectionProvider , EloquentProvider or even your own providers.
This would decouple the provider configuration from the engine and makes it easier to add new providers.
The Datatable should only contain the configuration of the data, while the Provider do all the heavy lifting with
the data.
I can imagine the column configuration be look something like this:
Datatable::data($provider)
->column('name') // just show the name column of the data without any additional configuration
->column('name', 'Username') // show the name column and map the view header cell to the name `Username`
->column('name', function($data) { return $data->username; }) // return custom data within a function
->column('name', 'Username', function($data) { return $data->username; }) // name, mapping and function
...The Datatable then holds a configuration of all columns and accepts the incoming request parameters.
It will then delegate the data processing to the Provider and will provide a ColumnConfiguration object and
a PresenterDetail or similar which will include information on what the frontend requested.
Internally I would like to change the structure to be more flexible.
E.g. we should only have one method that will accept the data Datatable::data($provider)
where the $provider will provide all the extra operations on the object.
I would also like to make the api more fluent.
The data(…) method will return a composer where all other base methods can be called upon:
->column('foo', function($data) { return $data->bar; })- Where should the declarations of searchable and orderable columns happen?
-
Normally it is part of the jquery declaration, but maybe it is easier to define it on the backend and transfer it to the frontend.
- Can we glue together the
data(…)andhtml(…)method? -
In my opinion it would be the best to declare the datable ones and get the same behaviour in the frontend and the backend, but I currently have no idea on how to achieve this.
- Can we include some adapters into the library?
-
I would love to include some common adapters into the library, like DatePicker, SingleColumnSearch or even an Editor with live update. I can imagine that it would look like this
Datatable::data(...)
->adapter(new SingleColumnSearchAdapter(...))
->adapter(
new EditorAdapter(
...model to edit,
...url to POST to
...fields to edit,
...template,
...etc
)
)Maybe we need to customize the javascript for that so we need to package that with the plugin