boboko/core
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Feat: Restructuring Products into the Concern Catalog, for future Collection services

Browse Source
This commit is contained in:
arvanitakis
2026-08-27 11:42:13 +03:00
parent 63caaf55c7
commit ba5a9523c8
20 changed files with 797 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/product-options.md
+8 -8
View File
@@ -6,7 +6,7 @@ Each `ProductOptionValue` carries a free-form `meta` jsonb column, but nothing i
Lunar's own admin UI exposes it — there's no way for an admin to, say, attach a hex
code to a "Red" value without editing the database directly.
`Modules\Core\Product\Contracts\ProductOptionTypeInterface` describes how a category
`Modules\Core\Catalog\Contracts\ProductOptionTypeInterface` describes how a category
of option behaves — what structured data its values carry in `meta`, and how an
admin edits that data — without introducing a new model. `ProductOption`/
`ProductOptionValue` stay exactly as Lunar defines them.
@@ -19,7 +19,7 @@ A shop registers a type class from its own service provider's `boot()`, the same
shape as `Modules\Core\Notification\NotificationRegistry`:
```php
use Modules\Core\Product\Services\ProductOptionTypeManager;
use Modules\Core\Catalog\Services\ProductOptionTypeManager;
ProductOptionTypeManager::get()->register([
\App\ProductOptions\ColorOptionType::class,
@@ -44,7 +44,7 @@ name/position, no extra meta form.
namespace App\ProductOptions;
use Filament\Forms\Components\ColorPicker;
use Modules\Core\Product\Contracts\ProductOptionTypeInterface;
use Modules\Core\Catalog\Contracts\ProductOptionTypeInterface;
class ColorOptionType implements ProductOptionTypeInterface
{
@@ -70,8 +70,8 @@ plain jsonb column). `getKey()` is the identifier used in the admin's "Option Ty
dropdown and in `ProductOption::meta['option_type']` — it has no relationship to the
`ProductOption::handle`.
A reference implementation ships at `Modules\Core\Product\OptionTypes\ColorOptionType`,
registered automatically by `Modules\Core\Providers\ProductServiceProvider` — no shop
A reference implementation ships at `Modules\Core\Catalog\OptionTypes\ColorOptionType`,
registered automatically by `Modules\Core\Providers\CatalogServiceProvider` — no shop
setup needed for it to appear in the "Option Type" dropdown, though an admin still
has to pick it per-`ProductOption` for it to take effect.
@@ -79,7 +79,7 @@ has to pick it per-`ProductOption` for it to take effect.
## How it's wired into the admin UI
`Modules\Core\Product\Services\ProductOptionTypeManager` is a singleton registry:
`Modules\Core\Catalog\Services\ProductOptionTypeManager` is a singleton registry:
- `get(): static` — the shared instance.
- `register(array $types): void` — registers one or more type classes, keyed
internally by `getKey()`.
@@ -93,11 +93,11 @@ Two extensions hook into Lunar's admin via its extension system
(`LunarPanel::extensions([...])`, registered in `CorePlugin`) — no forking of Lunar's
classes needed:
- `Modules\Core\Product\Filament\Extensions\ProductOptionResourceExtension` extends
- `Modules\Core\Catalog\Filament\Extensions\ProductOptionResourceExtension` extends
`Lunar\Admin\Filament\Resources\ProductOptionResource`'s own form with a `Select`
(`meta.option_type`) listing every enabled type's key. Shown only when at least one
type is enabled.
- `Modules\Core\Product\Filament\Extensions\ValuesRelationManagerExtension` extends
- `Modules\Core\Catalog\Filament\Extensions\ValuesRelationManagerExtension` extends
the "Values" tab's form. Its `extendForm()` reads
`$option->meta['option_type']` off the owning `ProductOption`, resolves it via
`ProductOptionTypeManager`, and appends `getMetaForm()`'s fields to the stock name