Open Flash Chart Laravel Package

Getting Started

This package is a Symfony 2.x bundle wrapping Open Flash Chart 2 (OFC2). There is no Laravel service provider, no config file, and no facade — it predates all of that. Treat it as a source of chart-building classes plus a .swf asset, not as an installable Laravel dependency.

Minimal steps to get anything on screen:

1. Check whether it installs at all. In a modern Laravel app composer require mch0lic/open-flash-chart will usually fail or drag in abandoned symfony/* 2.x constraints. If it resolves, pin it and move on; if not, vendor the chart classes by hand into app/Support/Charts/ and forget the bundle registration.
2. Copy the SWF and JS assets out of the bundle's Resources/public into public/vendor/ofc/ (open_flash_chart.swf, swfobject.js, ofc_embed.js). This is the step people miss — the bundle's asset publishing helper is Symfony-only.
3. Look at the chart classes first, not the bundle. The useful part is whatever builds the OFC2 JSON payload (title, axes, elements). The Symfony wiring around it is dead weight in a Laravel app.
4. Build your first chart as a JSON endpoint, not a view:

// routes/web.php
Route::get('/charts/revenue', [ChartController::class, 'revenue']);

// app/Http/Controllers/ChartController.php
public function revenue()
{
    $values = Order::query()
        ->selectRaw('DATE(created_at) as d, SUM(total) as t')
        ->groupBy('d')->orderBy('d')
        ->pluck('t')->map(fn ($v) => (float) $v)->all();

    return response()->json([
        'title'    => ['text' => 'Revenue'],
        'bg_colour' => '#ffffff',
        'x_axis'   => ['labels' => ['labels' => ['Mon','Tue','Wed','Thu','Fri']]],
        'y_axis'   => ['min' => 0, 'steps' => 1000],
        'elements' => [[
            'type'   => 'line',
            'colour' => '#2f7ed8',
            'values' => $values,
        ]],
    ]);
}

5. Embed it in Blade with swfobject pointing at that route:

<div id="chart-revenue"></div>
<script src="{{ asset('vendor/ofc/swfobject.js') }}"></script>
<script>
swfobject.embedSWF(
    "{{ asset('vendor/ofc/open_flash_chart.swf') }}",
    "chart-revenue", "100%", "300", "9.0.0",
    "expressInstall.swf",
    { data: "{{ url('/charts/revenue') }}?v={{ time() }}" }
);
</script>

First real use case: a single line chart on an internal dashboard where the audience is on a locked-down intranet with a legacy Flash-enabled browser. Outside that scenario, stop here and read Gotchas.

Implementation Patterns

JSON endpoint per chart. The cleanest pattern is one route per chart returning application/json, and the view only knows about the URL. This keeps chart data out of Blade, makes the payload testable with $this->getJson(...)->assertJsonStructure(...), and lets you cache responses independently.

Chart builder classes, not the bundle. Put a small Chart value object in your app that accumulates title, x_axis, y_axis, elements, tooltip, and exposes toArray()/toJson(). The package's classes are useful as a reference for key names; copying that ~200 lines of array-building is usually cheaper than fighting the Symfony coupling.

Transform in the query, format in the builder. Eloquent/pluck/groupBy does the aggregation; the builder only casts to float and pads gaps. Flash's parser is unforgiving about string numbers — cast aggressively at the boundary.

Multiple charts on one page. Each chart is its own SWF embed with its own JSON URL. Reuse one Blade component:

<x-ofc-chart id="chart-a" :src="route('charts.a')" height="260" />
<x-ofc-chart id="chart-b" :src="route('charts.b')" height="260" />

Cache the JSON, bust the SWF cache. Cache::remember("chart.revenue.{$range}", 300, ...) on the controller; append ?v= to the data URL in the embed. Without the cache-buster the Flash player will happily serve you yesterday's numbers.

Fallback rendering. Always ship a <noscript>/no-Flash fallback (an HTML table of the same series). Since you already have the aggregated data server-side, this is nearly free and is the only thing keeping the page useful post-Flash.

Integration tip: if you need something interactive in a modern browser, the OFC2 JSON shape is worth keeping and the SWF is not — you can feed the same payload to a small Chart.js adapter and migrate without touching your controllers.

Gotchas and Tips

• Flash is EOL since 31 Dec 2020. No current browser ships a Flash runtime. The only way this renders today is bundling the Ruffle WASM emulator and pointing it at the SWF, or running it in an isolated legacy VM. Factor that into any "assessment" before writing code.
• It is a Symfony bundle. AppKernel registration, services.yml, and the Resources/config wiring do nothing in Laravel. Do not try to register it as a provider; extract or copy the chart classes instead.
• Composer will likely refuse. The package's symfony/framework-bundle / symfony/http-foundation constraints target 2.x, which conflicts with any modern Laravel. Use --ignore-platform-reqs only if you're deliberately vendoring, and expect transitive breakage.
• JSON numbers, not strings. values must be a JSON array of numbers. pluck() from MySQL returns strings; a single "12" can silently blank the whole chart. Cast with (float) at the boundary.
• elements order is z-order. Later elements draw on top. Bar + line combos look wrong until you reorder.
• Gaps need null, not 0. A zero is a plotted point; null creates a break. Mixing them flattens your line to the axis.
• Axis quirks. y_axis.min is not auto-derived — set it explicitly or negative series get clipped. steps controls gridline spacing, not tick count.
• Content-Type matters. The Flash player is strict: return application/json and nothing else — no HTML error pages, no debug bar output. Laravel's debug toolbar or a stray dd() in the endpoint produces a blank chart with zero diagnostic information.
• Debugging is opaque. There is no console. Work in this order: (1) open the JSON URL directly in a browser, (2) validate with jq/a linter, (3) feed the same JSON into the OFC2 examples page if you still have a Flash-capable environment. Only then suspect the embed.
• SWF path is resolved relative to the embedding page, not the asset URL. Use an absolute asset() path or the embed silently 404s.
• No extension points worth the name. Custom element types require editing the SWF, which you can't. If the built-in line/bar/pie/hbar/area/scatter set doesn't cover the chart, that's your answer — hand-write the JSON against a JS library instead.
• Zero ecosystem signal. No stars, no dependents, no maintenance. Budget for owning the code outright from day one.