bnomei / kirby-blueprints

Kirby Ink - PHP Class based Blueprints for Kirby CMS

Hi there 👋

My name is Bruno Meilick.

• I work as a freelance web-developer using Kirby 3 CMS and Laravel.
• I create opensource, high quality Kirby CMS plugins.
• You can hire me to build your website or improve the performance of your Kirby CMS project.

kirby-blueprints's Issues

caching of queries

as another layer around the #5

generics, type hints and docblocks

https://blog.jetbrains.com/phpstorm/2021/12/phpstorm-2021-3-release/#improved_support_for_doctrine_collections

https://stackoverflow.com/a/25603986

Converter yaml to class

• create php copy next to yaml file.
• trigger validation an point out missing/broken stuff... or add comments in php code?

Validate class based vs yaml blueprints

the output as yaml should match the same setup in yaml

Discord notes

We think we need a class/object-based interpretation of blueprints if we want to get a blueprint editor (cause that needs to generate it's UI via reflections to also be able to support plugins etc.).

1. To get the architecture really right - for years to last
2. to get a good syntax
3. to make blueprint resolution async - so you can read a blueprint without every e.g. options query being evaluated (big problem currently with blueprints)
4. yes, a loooooot of blueprint options etc.
5. Needs to be super granular then, e.g. width: 1/3 probably needs a representaiton as ColumnWidth or FieldWidth as well

Putting them in a beta plugin doesn't make it easier to get the architecture right.
that's a bit naive, there's a lot more to it if we talk about filling blueprints with values, resolving them with a specific model etc.
Cause it'd make little sense for us to create something with so much work just to recreate the current status with its problems. If we touch this in such a major way, of course we want it to be much better than the current one.
sure maybe, but as always the tricky parts are in the details, the specific field options etc. so it's hardly a case of having 3-4 similar types of classes and just applying them everywhere. It's a lot of detailed and nested relationships.
All what I said was about our plans, not what your programmable blueprints needs. A blueprint editor needs to know what each option represents. But not just the editor, also the blueprints. If I want to resolve string option, the blueprint needs to know whether that string option can be i18n, can be a kirby query etc. - to resolve it correctly.

We don't have that quite yet. But basically: needs to be able to replace our whole blueprint and fields code currently spread over Cms and Form namespace and config files; needs to be able to access blueprint information independent of the model that gets applied to the blueprint to resolve e.g. options etc.; needs to allow a blueprint editor to transform that class/object structure in UI without the need to manually assign UI

That's for a start. But honestly, I don't think what you're planning to do goes into that direction. So it's rather about us learning some things here and there that we could adapt for ours too

lazy resolve of queries

via closures?

(optional) Allow for export to schema file

https://github.com/bnomei/kirby3-schema

type hints for models

how to make it work that using a model an ide can know the fields from the blueprint?

generate a model data file like @lukaskleinschmidt does?
https://github.com/lukaskleinschmidt/kirby-types

or flip it on the head and generate the blueprint from the model?
maybe have in the plugin index file the model export the blueprint definition so it can be loaded in the blueprints plugin extension?

a blueprint that not used in a model is of no use so can be ignored. we dont need the blueprint folder. just models with class compositions.

there are user and file models as well but should work similar.