Extjs Bundle Laravel Package

Getting Started

This bundle wires the Sencha ExtJS client framework into a Symfony 2 application: asset loading, a Twig bootstrap helper, and — the interesting part — an Ext Direct dispatcher that lets ExtJS call Symfony services over a single batched RPC endpoint.

Minimum steps:

composer require tpg/extjs-bundle

// app/AppKernel.php
$bundles = [ /* ... */ new Tpg\ExtjsBundle\TpgExtjsBundle() ];

# app/config/config.yml
tpg_extjs:
    library_path: "%kernel.root_dir%/../web/extjs"   # your Sencha SDK, not on Packagist

Import the bundle routing if you want Ext Direct (app/config/routing.yml → tpg_extjs: → @TpgExtjsBundle/Resources/config/routing.xml).

Where to look first: the repo README, then DependencyInjection/Configuration.php — that file is the real documentation for config keys. Then Resources/config/services.xml to see what services and tags you can hook into.

First use case: render a trivial ExtJS panel from a Twig template using the bundle's asset/init helper, confirm CSS/JS load. Then do the second use case, which is the reason to use this bundle at all: tag a service as a Direct provider, load the generated api.js in your app, and call one method from Ext.direct.Manager. If that round-trip works, the rest is just schema mapping.

Implementation Patterns

• Service-as-provider / Ext Direct remoting. Define a plain Symfony service with public methods, tag it as a Direct provider (check Configuration.php/README for the exact tag), and the bundle generates client stubs. This is the dominant pattern: repositories become grid stores (load/sync), form handlers become submit methods, and the client never sees Symfony routing.
• Controller discipline. Don't hand-roll JSON controllers for Direct endpoints. Use the bundle's dispatcher so batched arrays are unpacked correctly and replies are shaped as {type, tid, action, method, result}. Reserve normal controllers for page shells that render the ExtJS app.
• Screen workflow. API contract (service + tag) → generated stubs → ExtJS model/store with a proxy of type direct → grid/panel → Twig template that bootstraps the app. Keep the ExtJS app in web/js, keep the contract in Symfony.
• Twig integration. Use the bundle's helper to drop the ExtJS loader, the Direct API resource, and per-page bootstrap config into the layout, so each screen gets an isolated Ext.application without duplicating <script> tags.
• Validation bridge. If the bundle exposes form-to-ExtJS field mapping, lean on it; otherwise write a small transformer service that converts Symfony form errors into the {success: false, errors: {field: msg}} shape ExtJS renders natively. This is worth a dedicated class — you'll reuse it on every form.
• Auth boundary. Wrap the Direct route in your firewall and add a custom listener that rejects requests without a session/API token before the dispatcher runs. Direct bypasses the normal form-token flow, so treat the endpoint as a public API and guard it explicitly.

Gotchas and Tips

• It is archived (last release 2016). Assetic-era code, PHP 5/7-era constraints, no ^6/^7 Symfony. Do not attempt to compose it into a modern Symfony or Laravel app; treat the source as a reference implementation and port the Direct dispatcher contract if you need it.
• ExtJS is not a Composer dependency. You must vendor the Sencha distribution and point library_path at it. A wrong path is the #1 setup failure — usually silent, with a 404 for /ext-all.js that only shows in the browser network tab.
• Batching. The client sends an array of calls, not one request. A per-call exception must be caught and returned as {type: 'exception', tid, ...}; if the whole response 500s, every call in the batch aborts and debugging becomes opaque.
• Response shape is load-bearing. ExtJS expects success: false plus an errors map for sync failures. Returning a standard Symfony validation payload renders nothing in the grid and looks like a client bug.
• Debugging tip: add a kernel.request listener that logs $request->getContent() for the Direct route. The batched payloads are unreadable in the profiler otherwise.
• Config caching. The Twig globals and asset paths are compiled — cache:clear after changing library_path or you'll chase a phantom path bug.
• Extension points: the Direct provider tag and the API-generator service are the intended seams. If you need to rename methods, filter exposed services, or change stub generation, override the generator rather than patching the bundle (it's archived — you'll own the fork anyway).
• Fork advice: if you must keep it, pin composer.json exactly, commit the Sencha SDK into your repo, and add a smoke test that POSTs a batched Direct call and asserts the reply shape. That single test catches most of the failure modes above.