Propel Serializer Bundle Laravel Package

Getting Started

Start by reading composer.json to confirm the bundle targets Symfony 2.x-era APIs (it predates Symfony 4/5 Flex), then inspect the DependencyInjection/ and Resources/config/ directories — that is where the serializer services are registered and where you will discover the real service IDs and available configuration keys. The bundle is small, so the classes under the serializer/normalizer namespaces are your best documentation.

Minimal setup:

composer require smirik/propel-serializer-bundle

Register the bundle in app/AppKernel.php (older Symfony) or config/bundles.php (if it loads cleanly on your version):

new Smirik\PropelSerializerBundle\SmirikPropelSerializerBundle(),

Ensure Propel is already wired (via PropelBundle or your own Propel runtime config) and that the generated model classes are on the autoload path. Clear the cache so the DI container picks up the new services.

First use case: expose a Propel model as JSON from a controller. Build or fetch the object through its Query class, then hand it to the serializer service and return the result:

$book = BookQuery::create()->findPk($id);
$payload = $this->get('smirik_propel_serializer.serializer')->serialize($book);

return new JsonResponse(json_decode($payload, true));

If the service ID differs in this version, run php app/console debug:container | grep -i serializer (or bin/console on newer Symfony) to find what the bundle actually registers.

Implementation Patterns

Single-object serialization. Resolve the serializer service once and reuse it for single-record endpoints. This is the closest analogue to Laravel's response()->json($model) and is the fastest path to a working API endpoint.

Collection endpoints. Serialize arrays or PropelCollection results by iterating and serializing each row, or by passing the collection to the serializer if the bundle supports it. Prefer explicit iteration so you control pagination boundaries:

$books = BookQuery::create()->limit($limit)->offset($offset)->find();
$data = [];
foreach ($books as $book) {
    $data[] = $serializer->deserialize($book); // or ->toArray-style normalize
}

Field selection / partial payloads. Use per-call configuration (or a context/options argument if the serializer exposes one) to include or exclude fields, so that list endpoints return a lean shape and detail endpoints return the full object. Keeping the serialization contract explicit avoids leaking columns you later regret exposing.

Preload relations before serializing. Because Propel hydrates related objects lazily, call ->joinWith() or ->setFormatter() on the Query to fetch relations in the same round trip. This is the single biggest performance win and mirrors Laravel's ->with() eager loading.

Controller integration. Wrap the serializer in a small base controller helper or a dedicated presenter/transformer class rather than calling the bundle's service directly from every action. That gives you one place to change field rules, add envelope keys (data, meta), and swap the serializer if the bundle goes stale.

REST layer pairing. Route through FOSRestBundle or plain Symfony controllers; the bundle only concerns itself with turning Propel objects into arrays/scalars, so keep HTTP concerns (status codes, pagination headers) outside it.

Versioning your payload. Since the bundle gives you no schema, define your public API shape in a versioned transformer map keyed by model class. This isolates API changes from Propel model changes and makes the eventual migration off the bundle a per-transformer edit.

Gotchas and Tips

• Do not assume Laravel conveniences. There is no $hidden/$appends/$casts convention here; you must explicitly control what gets serialized. Propel models also hydrate columns as strings unless your schema casts them, so integer/boolean JSON types will often be wrong without post-processing.
• Lazy loading during serialization is a hidden N+1 trap. Accessing a related object inside the serializer triggers a query per row. Use joinWith() on the query, or limit serialization to foreign keys, not related objects.
• Circular references. Bidirectional Propel relations (Book → Author → Books) will recurse if the serializer walks relations. Prefer serializing only scalar columns and explicit relation summaries.
• The bundle is unmaintained at this point (0 stars, 0 dependents, legacy Symfony wiring). Budget for the possibility that the DI definitions or class signatures don't load on modern Symfony. If that happens, the classes are small enough to copy into src/Serializer/ and adapt — that is likely the safer long-term move than patching the vendor bundle.
• Debugging. Use debug:container to confirm service IDs and tags, and var_dump/Xdebug on the serializer instance to see what options it actually honors. Because there is no README-level documentation, treat the bundled tests (if any) as the specification.
• Extension points. The cleanest customization is to subclass or decorate the bundle's serializer service in your own bundle and register a compiler pass or services.yml override that replaces the smirik_propel_serializer.* alias. This lets you fix field rules without editing vendor code.
• Alternative to consider early. Propel models ship toArray()/fromArray() via BaseObject, and Symfony's own ObjectNormalizer with get* accessors works reasonably on Propel objects. If all you need is flat JSON, skip the bundle entirely and write a 30-line normalizer — you avoid the compatibility risk and keep full control of the output contract.