Weave Code
Datatables Bundle Laravel Package
omines/datatables-bundle
Symfony bundle that integrates the DataTables jQuery library for realtime Ajax tables. Decoupled from data sources, it ships with Doctrine ORM, MongoDB, and Elastica adapters for building custom, efficient tables in Symfony 6.4+.
Symfony DataTables Bundle with native Doctrine ORM, Elastica and MongoDB support
Frequently asked questions about Datatables Bundle
- Is omines/datatables-bundle a Laravel package, and can I use it in a Laravel application?
- No. It is a Symfony bundle with no Laravel service provider, no Eloquent integration, and hard dependencies on the Symfony kernel, DI container, Twig, and Flex recipe conventions, so its fit in a Laravel app is effectively zero without a full port. Laravel teams should use yajra/laravel-datatables or build a thin server-side-processing layer of their own. Only evaluate this package if your stack is Symfony 6.4 or newer.
- How do I install omines/datatables-bundle in a Symfony application?
- Run composer require omines/datatables-bundle and let the Flex recipe register the bundle, or add it manually to config/bundles.php. Run php bin/console assets:install to publish the bundle assets. The README deliberately leaves client-side jQuery and DataTables CSS/JS to you, so load them through your own asset pipeline. Then define a DataTable type class and call handleRequest, isCallback, and getResponse from your controller.
- Which Symfony and PHP versions does omines/datatables-bundle require?
- The bundle targets Symfony 6.4 and newer, which means it constrains your upgrade timing if you are still on older Symfony releases. It expects a PHP 8.x runtime alongside the standard Symfony kernel, DI container, and Twig integration. Pin the bundle version in composer.json and check the CI matrix in the repository for the exact tested combinations.
- Which data source adapters ship with omines/datatables-bundle, and why is there no DBALAdapter?
- Bundled adapters cover Doctrine ORM, MongoDB, and Elastica, while handling FOSElasticaBundle and Doctrine DBAL is documented as possible through custom adapters. There is intentionally no DBALAdapter out of the box, and the maintainers explain the reasoning in the linked pull request discussion. For raw SQL or complex reporting queries you write your own adapter against the adapter abstraction. That keeps request handling decoupled from the data source, but you should size the custom adapter effort before committing.
- How does the controller pattern work with handleRequest, isCallback, and getResponse?
- The API deliberately mirrors Symfony Forms. Your controller instantiates a DataTable type, calls handleRequest on the current request, returns getResponse when isCallback is true, and otherwise falls through to rendering a Twig template. Teams already fluent in Symfony Forms ramp up very quickly. The documentation recommends encapsulating each table as a reusable type under something like App\DataTable to keep controllers thin.
- How do I secure a DataTable, covering column mapping, search whitelisting, and row-level authorization?
- Security is caller-owned: the bundle handles request parsing and response shaping, not access control. Whitelist searchable and orderable columns explicitly, map only the columns you intend to expose, and enforce row-level visibility in the adapter or query layer, for example with a Doctrine query builder filter. The bundle does not provide row-level access control, so an authorization mistake in your adapter is a data leak.
- How should I manage the jQuery and DataTables client assets: Encore, CDN, or assets:install?
- The bundle leaves client dependencies to the implementer, so pick one approach and be consistent. Webpack Encore with pinned jQuery and DataTables versions gives reproducible builds, whereas ad hoc assets:install plus CDN defaults does not. Note that language_from_cdn pulls i18n files from the DataTables CDN, which breaks in air-gapped or strict-CSP environments, so switch to Symfony translations in those cases.
- How do I test a DataTable in a Symfony application?
- Keep table definitions in dedicated type classes so they can be unit tested and reviewed independently of controllers. Functional tests can issue Ajax-style requests carrying the DataTables draw, start, length, search, and order parameters, then assert on the returned JSON payload. Assert your authorization cases too, not just the happy path, since the bundle will not enforce row-level access for you.
- Is omines/datatables-bundle actively maintained and safe to use in production?
- It is maintained by Omines as an internal tool released publicly, with a small maintainer pool, no commercial SLA, and MIT licensing with no warranty. Ecosystem signals are modest, at around 284 GitHub stars and very few listed dependents, and the maintainers ask users to route questions to Stack Overflow because of limited bandwidth. Nothing in the code is a red flag for Symfony 6.4+ projects, but decide up front who owns the fork or patch path if upstream stalls.
- What are the alternatives to omines/datatables-bundle for server-side DataTables?
- On Laravel, yajra/laravel-datatables is the established choice, or you can build a thin in-house server-side-processing layer. On Symfony, this bundle is a reasonable pick when you want the adapter abstraction, though teams needing raw SQL must add a custom adapter, and FOSElasticaBundle integration follows the same custom-adapter path. There is no automated migration from hand-rolled server-side handling, so migrate table by table and wrap each one as a reusable DataTable type.
Weaver
How can I help you explore Laravel packages today?