Daplos Parser Bundle Laravel Package

Getting Started

DaplosParserBundle is a Symfony bundle, not a Laravel package — this is the first thing to internalise. The release notes promise "no configuration," which for Symfony means the bundle registers its services via services.yaml/autoloading and is picked up by config/bundles.php. In Laravel there is no bundle registry, so you will be wiring it manually.

Minimal steps:

1. Install and inspect before you write code.

   composer require farm-public/daplos-parser-bundle
   ls vendor/farm-public/daplos-parser-bundle
   cat vendor/farm-public/daplos-parser-bundle/composer.json
   

   Check the type field (symfony-bundle confirms bundle status), the require block (PHP version, symfony/* constraints), and whether an autoload.psr-4 namespace exists. That namespace is the entry point you will reference from Laravel.

2. Look for the service class first, the DI wiring second. In a Symfony bundle the interesting object is usually a parser/reader service under src/, registered in Resources/config/services.xml|yaml (or config/services.php on newer skeletons). Read that registration file — it tells you the constructor arguments and the public service ID you need to instantiate yourself. Do not start with the bundle class (*Bundle.php); it is almost always empty boilerplate.

3. Confirm the input format before promising anything. DAPLOS is a French agricultural parcel exchange format; in practice you will be feeding it XML (and possibly zipped/geo-referenced variants). Get one real, small sample file from your users and run it through the parser in php artisan tinker before building anything around it. The release notes contain zero information about accepted encodings, schemas, or versions — verify empirically.

4. First use case. A one-off artisan command that takes a file path, parses it, and dumps the resulting objects:

   // app/Console/Commands/InspectDaplos.php
   $parser = app(\FarmPublic\DaplosParser\DaplosParser::class); // adjust to the real class
   $result = $parser->parse(storage_path('app/daplos/sample.xml'));
   dump($result);
   

   Register a binding in a service provider so you are not new-ing it across the codebase:

   $this->app->singleton(\FarmPublished\...\Parser::class, fn () => new \...\Parser(/* args from the bundle's services file */));
   

   Keep that binding in a single dedicated provider (DaplosServiceProvider) so that swapping the parser out later is a one-file change.

Implementation Patterns

Adapter wrapper (recommended default). Because the package is 0.1.0 and Symfony-flavoured, never let its types leak into your domain. Define App\Daplos\DaplosImporter with a import(string $path): ImportResult method; the wrapper owns the third-party call, the try/catch, and the mapping to your own DTOs. When the package's namespace or return types shift (they will), you edit one class.

Parse-then-persist, never parse-then-respond. DAPLOS files can be large and parsing is CPU/memory bound. Pattern:

• Controller accepts an upload, stores it on the local/s3 disk under a ULID-named path, records a daplos_imports row with status pending, and dispatches a job.
• Job resolves the wrapper, parses, bulk-inserts parcels/plots in a transaction, sets status completed or failed with the exception message.
• This gives you idempotency (re-run the job on the same stored file), auditability (keep the original), and no web-request timeouts.

Streaming / chunking where the parser allows it. If the parser exposes an iterator or a callback-style API, prefer it over a parse(): array that materialises everything. If it only offers the latter, wrap the job with ini_set('memory_limit', ...) scoped to the job and consider proc_open-ing an artisan command if files exceed a few hundred MB.

Validation as a separate layer. Do not rely on the parser to reject bad input — its error behaviour is undocumented in 0.1.0. Sanity-check the file yourself before handing it over: exists, size, MIME/extension, and a cheap XMLReader/simplexml well-formedness probe. Fail fast with a message your users understand, not a TypeError from deep inside vendor code.

Result normalisation. Map parsed output into your schema with explicit field-by-field assignment (not (array) $dto or get_object_vars). This is the difference between a silent data corruption bug and a loud one when the package changes property names.

Integration tip — feature-flag it. Put the import behind a config flag and a single route. At 0.1.0 you want the blast radius of a bad release to be one endpoint, not the whole app.

Testing. Write a fixture-based test with a hand-crafted minimal DAPLOS file committed to tests/Fixtures/. Assert on your DTOs, not the vendor's objects. This is your regression net when 0.2.0 lands.

Gotchas and Tips

Symfony bundle ≠ Laravel package. There will be no service provider, no config/*.php to publish, no facade. Any Symfony\Component\* interfaces the parser type-hints against must already be satisfied by Laravel's own dependencies (Laravel ships many Symfony components, but not all, and not always at compatible versions) — or you will hit Class not found / version conflicts at runtime. Run composer why symfony/http-foundation before and after install.

"No configuration" is a limitation, not a feature. At 0.1.0 there are no knobs for encoding, delimiter, schema version, or strictness. When you hit a file that does not parse, your only options are patching the vendor package (use repositories + a VCS fork, not manual vendor/ edits) or normalising the file upstream. Budget for this.

Encoding is the most likely first bug. French DAPLOS data commonly carries accented characters and may not be UTF-8. If you get mojibake in commune names or preg_match failures, inspect the raw bytes with file -i and check the XML declaration's encoding attribute before blaming the parser. Convert to UTF-8 at ingest and store the normalised copy.

0.1.0 means zero BC guarantees. The changelog link is the only documentation. Pin exactly ("farm-public/daplos-parser-bundle": "0.1.*"), commit the lock file, and read the diff of every patch release before bumping. Semver rules are effectively suspended below 1.0.

Debugging inside vendor code. You will end up there. Use dd()/dump() sparingly — prefer ray() or a step-through with Xdebug, and always remove instrumentation. Better: enable Symfony's DebugClassLoader-equivalent by running your fixture test with --debug and catching deprecations early.

Error semantics are unknown. Wrap every call in try/catch (\Throwable $e) rather than guessing the exception class. Log $e::class, message, and the offending file path — you will need that when filing an issue. Treat any partial result as no result; do not persist half a file.

Extension points to watch for as it matures. The natural places a bundle of this shape grows are: a parser interface you can swap, event dispatching per record, and a configuration tree for strictness/encoding. When those appear, your adapter wrapper and your fixture test are what let you adopt them in an afternoon instead of a sprint.

Where to file feedback. The repo (FarmPublic/DaplosParserBundle) is the only channel — no docs site exists. If you need encoding control or a streaming API, open an issue early; at 0.1.0 maintainers are still shaping the public surface, and this is the cheapest moment to influence it.