Download the PHP package omerkoseoglu/devextreme-data-symfony without Composer

DevExtreme Data for Symfony

Unofficial. This is an independent, community-maintained port. It is not affiliated with, endorsed by or supported by Developer Express Inc. "DevExtreme" and "DevExpress" are trademarks of Developer Express Inc.

Symfony bundle for omerkoseoglu/devextreme-data: answer DevExtreme widget requests (DataGrid, PivotGrid, SelectBox, ... with remoteOperations) from Doctrine DBAL queries, ORM entity mappings, tables or arrays. Filtering, sorting, paging, grouping and summaries run in the database.

Requires PHP 8.2+ and Symfony 7.4 or 8.x. Doctrine sources need a pdo_sqlite, pdo_mysql or pdo_pgsql DBAL driver.

Install

Symfony Flex enables the bundle; otherwise add it to config/bundles.php:

Optional config/packages/devextreme_data.yaml:

Usage

$loader->load($source) returns the LoadResult object (JSON-serializable) instead. Parameters come from the query string, form fields or a JSON body. Malformed requests (bad JSON, mixed and/or, unknown field, ...) throw BadRequestHttpException, which Symfony renders as HTTP 400.

Controllers can also type-hint the parsed options:

Sources

EntitySource::for($em, Order::class) builds a source from the Doctrine mapping: table, mapped properties (embeddables become nested objects) and identifier. The client sees property names, never column names; owning many-to-one associations are exposed under the association name and hold the foreign key. Restrict what is visible with fields: ['id', 'total'].

DbalSource::forQueryBuilder($connection, $qb, columns: [...], primaryKey: ['id']) accepts any DBAL query builder, including joins, named parameters (:name), IN (:ids) arrays and DateTimeInterface values:

columns is a whitelist (client field => output column of your query, or a trusted Raw expression); dotted names become nested JSON. Without it any plain column name of the query is accepted. Use it in production.

DbalSource::forTable($connection, 'orders', ...), arrays/iterables (handled in memory) and any DataSourceInterface work too.

Known limitations

• Scalar rows, no hydration. No entities, lifecycle events or Doctrine type conversion: dates are strings, booleans are 0/1 on most drivers.
• *`pdo_drivers only** (pdo_sqlite,pdo_mysql,pdo_pgsql). mysqli and other drivers throw aLogicException`.
• Queries bypass the DBAL layer. They run on the native PDO connection, so Doctrine's SQL logger, the Symfony profiler's database panel and DBAL middlewares do not see them.
• Doctrine SQL filters are not applied (soft-delete, tenancy). Put such constraints into the DbalSource query or the where: / whereParams: arguments of EntitySource.
• EntitySource exposes mapped fields and owning many-to-one associations (as the foreign key). Collections (one-to-many, many-to-many) are not exposed, and entities with inheritance mapping are rejected: use DbalSource.
• The query builder is captured once when DbalSource::forQueryBuilder() is called. Array parameters are supported with named placeholders only (IN (:ids)).
• Dates and timezones: filter dates are compared as wall-clock time and never converted; see the core package's known limitations (browser Date values reach the server as UTC).
• Tested with Doctrine DBAL 4 and ORM 3 on Symfony 7.4 and 8.x (PHP 8.2+).
• All filter values are bound parameters; field names are whitelisted (mapping or columns) or identifier-checked.

Development

The tests boot a real Symfony kernel with an in-memory SQLite database and run the core package's SQL-vs-memory parity matrix against EntitySource, DbalSource::forTable and DbalSource::forQueryBuilder, plus HTTP-level behaviour.

MIT licensed.