|
| 1 | +# Idea |
| 2 | + |
| 3 | +https://github.com/nunomaduro/skeleton-php |
| 4 | + |
| 5 | +- We do not have real translations (of fields) in Builder, that's odd |
| 6 | +- We cannot add contexts as the command is not flexible, it just knows preview and package (and falls back to app, I guess). It should be using the config and the config can have custom contexts. Another thing, contexts are taken from builder.php not pro/builder.php, why? |
| 7 | +- CustomDemo ausbauen, FullItemPreset with all Blocks, see if all blocks are ready for prime time |
| 8 | +- Translatable Block and TranslatableItemPreset |
| 9 | +- visible for features that depend on deleted tab must be compatible with translations |
| 10 | +- Installer in Moox Core - https://chatgpt.com/c/675da73e-ed6c-800c-8a7a-6a886fa78f1f |
| 11 | +- We have dependencies, these must be given to a package or app's composer.json ... but how? Also for preview ...? Maybe in first iteration it is just an informal message? |
| 12 | + - Nested Taxonomy - Lazychaser Nested Set |
| 13 | + - Translatable - Moox Languages |
| 14 | + - Media Library Field - Spatie Media Library and Filament Spatie ML |
| 15 | + |
| 16 | +## Translatable |
| 17 | + |
| 18 | +- Moox Data Languages |
| 19 | +- Moox Languages |
| 20 | +- Moox Translatable - Traits ... |
| 21 | + |
| 22 | +## Media |
| 23 | + |
| 24 | +- siehe Media |
| 25 | + |
| 26 | +## New Laravel |
| 27 | + |
| 28 | +Of course you can use Builder in existing projects, but the best way to use Builder is to create a new Laravel project |
| 29 | + |
| 30 | +```bash |
| 31 | +composer create-project laravel/laravel buildertest |
| 32 | +``` |
| 33 | + |
| 34 | +Using Laravel Herd for example this should work: http://buildertest.test/ |
| 35 | + |
| 36 | +Create a database and wire it in your .env |
| 37 | + |
| 38 | +## Install |
| 39 | + |
| 40 | +Install Moox Builder |
| 41 | + |
| 42 | +```bash |
| 43 | +composer require moox/builder |
| 44 | +``` |
| 45 | + |
| 46 | +Route http://buildertest.test/builder da, Filament nicht? Müsste Core übernehmen? |
| 47 | + |
| 48 | +Idee: ein Installer für alle, der entsprechend |
| 49 | + |
| 50 | +- Immer Filament prüfen muss oder installieren |
| 51 | +- Alle Tabellen und Plugins prüft und installiert |
| 52 | + |
| 53 | +Das einzige was mir aufgefallen ist, das wenn man bei Content zu viel Text eingegeben hat, dass dann diese Fehlermeldung kam: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'content' at row 1 |
| 54 | + |
| 55 | +I want to work with you on my project Moox Builder. The project is well documented in README.md and the current state and open issues can be found in DEVLOG.md |
| 56 | + |
| 57 | +Please always stick to the rules in README and keep DEVLOG always updated. And please don't assume anything, instead ask for files. |
| 58 | + |
| 59 | +One of the most important files is the builder.php config file that contains the wiring for contexts etc. |
| 60 | + |
| 61 | +We need to work on the next Task in DEVLOG. |
| 62 | + |
| 63 | +## Compatibility |
| 64 | + |
| 65 | +All Moox Packages and Plugins are versioned together to one mayor version, currently **v4**. |
| 66 | + |
| 67 | +The PHP compatibility is based on Laravel, visit [https://laravel.com/docs/11.x/releases](https://laravel.com/docs/11.x/releases#support-policy) for details, and defined in Moox Core's composer.json. |
| 68 | + |
| 69 | +| Moox | PHP | Laravel | Filament | Livewire | Tailwind | |
| 70 | +| ---- | :-------: | :-----: | :------: | :------: | :------: | |
| 71 | +| <4 | 8.0 - 8.2 | 10,11 | 3.2 | 3 | 3 | |
| 72 | +| 4 | 8.2, 8.3 | 11 | 4 | 3 | 3 | |
| 73 | + |
| 74 | +Excluding Moox Press there are no database-specific implementations, so all database drivers should be working. However, we develop, test and deploy using MySQL, we are not able to reproduce issues on other DBMS. |
| 75 | + |
| 76 | +## Restoring entities |
| 77 | + |
| 78 | +Generation of entities is currently done by directly accessing the classes. If we want to restore entities from a build, we need to use the data array. |
| 79 | + |
| 80 | +The current state of the data array is: |
| 81 | + |
| 82 | +✓ useStatements (model, resource, pages) |
| 83 | +✓ traits (model, resource, pages) |
| 84 | +✓ methods |
| 85 | +✓ formFields |
| 86 | +✓ tableColumns |
| 87 | +✓ block type and options |
| 88 | +✓ migrations |
| 89 | + |
| 90 | +Missing: |
| 91 | + |
| 92 | +- Form sections and meta sections (see Publish block lines 77-89) |
| 93 | +- Page-specific methods (see Publish block lines 63-72) |
| 94 | +- Form actions |
| 95 | +- Table filters |
| 96 | +- Table actions |
| 97 | +- Navigation settings |
| 98 | +- Resource configuration (icons, labels, etc.) |
| 99 | +- Context information (namespace, paths) |
| 100 | +- Relations configuration |
| 101 | +- Validation rules |
| 102 | +- Config entries |
| 103 | +- Sections |
| 104 | + |
| 105 | +After adding the missing data, we need to implement the RestoreService and use it in the UI. |
| 106 | + |
| 107 | +## Packages |
| 108 | + |
| 109 | +Current Status: |
| 110 | + |
| 111 | +- Files are prepared: Service, Generators, Templates and Commands |
| 112 | +- Config is prepared |
| 113 | +- Install Template and Readme are not finished, as well as their partials |
| 114 | +- All templates could be completely prepared |
| 115 | +- Then we could go for the Generators |
| 116 | +- Then the Services |
| 117 | +- Finally the Commands |
| 118 | + |
| 119 | +- We need Preparation to be able to install packages locally, `PrepareAppForPackagesCommand` |
| 120 | +- Create a /packages directory |
| 121 | +- Paste `composerrepos.stub` into composer.json |
| 122 | +- Generate an empty package, where we are able to generate Entities in package context with the `CreatePackageCommand`, it uses the `PackageGenerator` Service that iterates over the new `package_generator` config key, that conntects the Generators and the Templates. |
| 123 | + |
| 124 | +- Now we can `Generate Entities` into that package |
| 125 | +- Generate the Entity in Package context |
| 126 | +- Generate the Resource part in the config, like wired in the `package_entity_enabler`config key |
| 127 | +- Generate the parts into the installer, like wired in the `package_entity_enabler`config key |
| 128 | +- Generate the part into the README, like wired in the `package_entity_enabler`config key |
| 129 | +- For activation of packages, I also created a config key `package_entity_activator`, that just wires the `PackageActivator`Service used by the `ActivatePackageCommand` |
| 130 | + |
| 131 | +- We need to require the package using composer |
| 132 | +- We need to run php artisan package:install |
| 133 | +- Finally the `PackagePublisher` service used by the `PublishPackageCommand` |
| 134 | + |
| 135 | +- Create a Git repo |
| 136 | +- Publish to GitHub |
| 137 | +- Add the package to Moox Monorepo |
| 138 | +- Publish to Packagist - https://packagist.org/apidoc#create-package |
| 139 | + |
| 140 | +- Later we'll need a `RemovePackageCommand` that uses the `PackageRemover`service |
| 141 | +- Last the `AbstractPackageService` |
0 commit comments