Omnisense: the Omni ecosystem and its documentation
One prefix, several families 246 packages · 25 families
The core of the sites, and optional ready-made structures.
A — The foundation
The core, the families, the bridges
What any site may take: omnibase, the core of the sites; the families, one contract per domain, fulfilled service by service by their providers; the bridges, which tie it all to a framework. The providers are not listed here: they are searched for.
omnisense/omnibase
The core every site starts from: accounts and security, back office, translations, images, forms.
1 package
2
Families
omnisense/omni<domain>
The contract of one domain - parcels, payments, public registers, science data - in plain PHP, whoever the service behind it. Under omnisense/, or still glitchr/ for those not moved yet.
omnisense/omnibusomnisense/omnitrade+ 23
25 packages · 180 providers to search
3
Bridges
omnibridge/<target>
The glue between the core and a framework, a storage or a view layer. It knows no structure: one bridge serves them all.
omnibridge/composeromnibridge/doctrineomnibridge/eloquentomnibridge/laravel+ 5
9 packages
A site takes the core, the families it calls on and the bridges of its framework. A prepared structure is added when it saves time: nothing in the core or the families depends on one. Plus 2 JavaScript libraries.
B — The families
A contract per domain, a package per service
A family writes down once what a domain asks of outside services - rates and labels for parcels, payments and refunds for trade - and each provider fulfils it for one service. Changing service is changing a line of configuration.
- Omnibus Ship a parcel, whatever the carrier. 23 providers
- Omnitrade Take payments and sell, whatever the provider. 6 providers
- Omnistate Ask the public registers what they know. 8 providers
- Omnibank Read a bank account. 4 providers
- Omnisong Let a musician's catalogue be heard. 2 providers
- Omnipost Publish on the social networks, and share a page to them without their scripts. 2 providers
- Omnifood Receive a restaurant's orders and reservations. 5 providers
- Omnischolar Gather a researcher's publications. 7 providers
- Omnilab Read what science knows of a thing, or measures at a place. 56 providers
- Omnilex Read the sources of law. 4 providers
- Omnimeet Open a video room and let someone in. 2 providers
- Omnishield Guard a form: captcha, spam, addresses known for abuse. 6 providers
- Omnisign Have a document signed. 3 providers
- Omnibill Send and receive an electronic invoice. 3 providers
- Omniauth Sign people in, by whichever factors. 4 providers
- Omnidrive Read and write files, wherever they are kept. 8 providers
- Omnimap Draw a map, whoever provides it. 3 providers
- Omnisearch Search, whatever the engine. 1 provider
- Omniplay Put a game on the stores, and play it online. 7 providers
- Omniticket Read the tickets sold elsewhere. 5 providers
- Omnidns Manage a domain name where it is registered. 4 providers
- Omnidocs 5 providers
- Omnifund Read who funds a project. 3 providers
- Omnireach Read what outside tools know of a site's audience. 5 providers
- Omnireview Read what customers say elsewhere. 3 providers
- JavaScript libraries The house's JavaScript libraries, without dependency. 2 libraries
C — omnibridge
One bridge per framework, not one per structure
The core knows no framework: a bridge ties it to Symfony, to Laravel, to Doctrine, to Twig, to React - a generic glue that knows no structure. Another framework is one more bridge, not a rewrite of every structure.
- omnibridge/symfony Container, routing, forms, security. In the catalogue
- omnibridge/laravel The core’s contracts on Laravel’s container. In the catalogue
- omnibridge/doctrine Storage: Doctrine stands on its own. In the catalogue
- omnibridge/twig Rendering: Twig stands on its own. In the catalogue
- omnibridge/react Pages as React components, from any framework. In the catalogue
- omnibridge/composer Installation: the stubs and the core’s declared patches. In the catalogue
- omnibridge/static A static export of any application’s public pages - this site. In the catalogue
D — Optional Prepared structures
A ready-made structure, when it saves time
A ready-made structure for one trade - entities, screens, back office, translations, demo data - already assembled on the core. Optional: take one to go fast, or write your own on the core and the families.
omnibase/<trade>
omnibase/adminomnibase/agendaomnibase/blog+ 26
29 structures
Nothing in the core or the families depends on them. Symfony today, as the core is; all of them are in the package search.
E — Compatibility
Any framework: the families in plain PHP, the core through its bridges
What is true today. No date is promised for the rest.
Today The families run in plain PHP
The core of an omni* family requires neither Symfony, nor Doctrine, nor Twig: only standalone libraries. Its registry is built by hand, in a script, a Laravel or a Symfony application. The Symfony bridge is in the package, under Bridge/Symfony, and nothing of it is loaded elsewhere.
use Omnitrade\PayPal\PayPalGatewayFactory;
use Omnitrade\Registry;
use Symfony\Component\HttpClient\HttpClient;
// No container, no kernel: the registry is built by hand.
$registry = new Registry([new PayPalGatewayFactory(HttpClient::create())], [
'paypal' => ['factory' => 'paypal', 'options' => ['client_id' => $id, 'secret' => $secret]],
]);
$gateway = $registry->get('paypal');The proof: each family has a framework-free test (Tests/BareTest.php) that builds its registry by hand and checks that no framework class is loaded.
Today omnibase 4 runs through its bridges
omnisense/omnibase 4.x requires only its framework-free foundation: Symfony comes through omnibridge/symfony, Laravel through omnibridge/laravel, the storage and the rendering through omnibridge/doctrine and omnibridge/twig.
Next The prepared structures follow
The prepared structures omnibase/* are Symfony bundles on the core today; each moves its trade to the root of its package (objects, rules, contracts) as it is reworked, its framework parts into bridges. The generic glue, which knows no structure:
That glue is omnibridge, described above.
The detail, and what it asks of each package: the Compatibility page of the documentation.
F — Read
Every package has its manual
The manuals are the Markdown files of each repository, as they are written there: a version per branch, a link to the file to correct it.
- packages in the catalogue
- 246
- manuals published
- 241
- families
- 25
News
-
Six new families, GitHub Pages, manuals by series
The website is published on GitHub Pages through omnibridge/static; omnifund, omnidns, omniticket, omnireach, omnifilm and omnigame join the catalogue; omnidrive gains four providers; flowjs 1.5.2; omnibase's manual for 4.x and 3.x side by side.
-
omnibridge/static - a static export for any application
The omnibridge family gains a generic exporter - an application's public pages rendered at build time by its own code, for any static host.
-
This website is now static
Guides, news, the catalogue and every package's manual, built from files and served without a server-side application.