Weave Code
Devexpressbundle Laravel Package
elma/devexpressbundle
Symfony bundle that bridges DevExpress JS widgets with Doctrine, currently supporting dxDataGrid. It parses DevExpress load options and applies filtering, sorting, and pagination to Doctrine queries via simple column-to-field mapping. Unofficial and a work in progress; contributions welcome.
At a glance
Frequently asked questions about Devexpressbundle
- Can I use elma/devexpressbundle in a Laravel application?
- No, not directly. The package is a Symfony bundle registered through AppKernel::$bundles (Bilendi\DevExpressBundle\BilendiDevExpressBundle), with no service provider, facade, or publishable config. Using it in Laravel means porting the parser and Doctrine query handler internals into a service provider, which is a re-implementation rather than an integration. If you want the dxDataGrid-to-Doctrine translation in Laravel, budget for that port explicitly.
- How do I install elma/devexpressbundle?
- Run composer require elma/devexpressbundle "~1.0@dev" and then register new Bilendi\DevExpressBundle\BilendiDevExpressBundle in the $bundles array of app/AppKernel.php. There is no Flex recipe, no bundle auto-discovery, and no stable tagged release, so Composer pins you to a development branch. The README assumes a legacy Symfony application layout.
- Which Symfony and Doctrine versions does this bundle support?
- The registration idiom targets Symfony 2.x/3.x, before Flex and the modern skeleton. There is no evidence of maintenance against Symfony 5, 6, or 7, and the dependency constraints may not resolve against current symfony/* releases. Doctrine assumptions around the query builder and alias conventions may also be stale. Verify compatibility with a throwaway branch before committing to it.
- Does elma/devexpressbundle include the DevExpress JavaScript libraries?
- No. The README states explicitly that the bundle ships no DevExpress library files, so the commercial DevExpress JS assets must be licensed and vendored separately. That makes DevExpress licensing and version pinning your responsibility, and the bundle does nothing to keep client and server versions aligned. Confirm you already hold a DevExpress license at the version you plan to use.
- Is the column-to-field map in elma/devexpressbundle safe from SQL injection?
- The map is the security boundary: it translates DevExpress column identifiers into DQL fields used in sorting and filtering clauses. If loadOptions identifiers can reach the map unvalidated, or if the map is built from request data, you have an injection vector through ORDER BY or WHERE. Keep the map static and server-controlled, and code-review the parser before exposing it. Do not assume the package sanitises this for you.
- Does elma/devexpressbundle support DevExpress reporting, charts, or schedulers?
- No. Currently only a dxDataGrid bridge is provided, covering paging, sorting, and filtering. Reporting, charts, schedulers, and export are out of scope and will not arrive through this dependency. If grid support is a wedge for a broader DevExpress feature set, this package cannot carry that roadmap.
- Is elma/devexpressbundle maintained, and does it have a stable release?
- Treat it as low-maintenance: the last release was April 2020, it has a handful of stars and no dependents, and the README labels it a work in progress that is unofficial and incomplete. There is no stable tagged release, only ~1.0@dev. If your dependency policy forbids dev-branch pins, this package fails that policy outright.
- How do I return paginated dxDataGrid data and a total count with Doctrine?
- Instantiate SearchQueryParser, decode the loadOptions request parameter, and pass the result to parse(). Build a DoctrineQueryConfig with your column map, create a query builder, then wrap it in DoctrineQueryHandler and call addAllModifiers() to apply filtering, sorting, and paging. Return the fetched rows under content and the unpaged count under total, which is the shape dxDataGrid expects. Keep both queries built from the same base query builder so the counts stay consistent.
- How should I test elma/devexpressbundle integration in my application?
- The loadOptions parsing is plain PHP, so unit-test it by feeding decoded DevExpress payloads with known filters, sorts, and paging and asserting the resulting criteria. For the Doctrine side, use an in-memory SQLite database and assert the generated SQL and result sets rather than mocking the query builder. Add a regression test that an unknown or tampered column identifier is rejected by the map. Because the package is unmaintained, your own tests are the only safety net you will have.
- What are the alternatives to elma/devexpressbundle for server-side DevExpress grid filtering?
- The core logic is a few hundred lines of straightforward loadOptions-to-query translation, so owning it in-house is a realistic option and removes an unmaintained dev-branch dependency. In Laravel you would write a request parser plus a query-builder adapter behind a service provider, which also lets you enforce a whitelist for sortable and filterable columns. For general server-side table handling, mainstream Laravel query-builder and DataTables-style packages are better supported, though none speaks the DevExpress payload natively.
Weaver
How can I help you explore Laravel packages today?