luya-module-cms Blocks + Placeholder recursion

[tskodaw]

feature requests/design requests for discussion:

• It would be great to have restrictions for blocks in placeholders like Blockgroup/Interface matchings. In two ways, a Block can restrict "children" Blocks, and a block can desire a certain type of parent block. Or even better, a parentBlock should have the possibility to catch an event, when a childblock is inserted, to deny this or accept this.
• While rendering CMS-Blocks, I think it would generally be nice to have more control from parent/containing blocks about what is going on in it's children/placeholder contained blocks. Like a bubbling up beforeRenderChildBlock(PhpBlock $childBlock)

Why?

The desire for it arose while I was experimenting with creating a Form-Block, containing InputField-Blocks:

in the editor-view:

on the page:

(angular+php parts): There should be a Form-Block, containing in it's placeholders Inputblocks (i.e. TextInput-Block, Date-InputBlock, SelectInput-Block etc.) and managing the whole thing in general (like generate the Datamodel, starting the ActiveForm). The Inputblocks in my actual idea are using features of the parent* block, so putting an Inputblock into a normal Layoutblock, not having a FormBlock somewhere "upstream" already initialized leads to errors (for instance the used datamodel for the whole form is not instantiated, no ActiveForm instantiated).

typematch/insert-event leads to sth like:

Why formdesign in CMS?: Using the CMS with it's blocks is really cool, because the editors can be more involved in planning/designing the form not requiring someone to change any view-files all the time their ideas change. Constructing forms should nevertheless be error-tolerant to those content-editors, so if they want to put an Inputfield somewhere not applicable, it should somehow be forbidden.

(php-part) Further, the FormBlock should perhaps have some control before an Input-child Block is rendered, like injecting the datamodel-object or prevent child rendering under certain conditions. like $blockObject->onBeforePlaceholderBlockRender($cancel, $childBlock) and $blockObject->onAfterPlaceHolderBlockRendered($childBlock) with the possibility of bubbling it up so that in this case the FormBlock knows when somewhere down the recursion a InputBlock is going to be rendered.

Use: for instance I plan on generating (in PHP, not in any fancy special Javascript works) like a Form that has "slides" so my FormBlock, can contain SlideBlocks, those can contain InputFieldBlocks. The FormBlock should manage which slide to render, dataflow etc. like allowing slide-child 1 to be rendered, and slide-child-2 to not beeing rendered at one moment.

for the onBeforeChildRender/afterChildRender thing a starting point is in the NavItemPage recursion:

luya\cms\models\NavItemPage:265 (as a point to start, the specific "event"call seems to have to be somewhere else down in the recursive function)

$blockObject->setEnvOption('equalIndex', $equalIndex);

                    // render sub placeholders and set into object
                    $insertedHolders = [];
                    foreach ($blockObject->getConfigPlaceholdersExport() as $item) {
/** ---> something like
***  if($blockObject->beforeRenderPlaceholderItem( $ConfiguredBlockItemToBeRendered)){ **/
                        $insertedHolders[$item['var']] = $this->renderPlaceholderRecursive($navItemPageId, $item['var'], $placeholder['id']);

/** --> and $blockObject->afterRenderPlaceholderItem($placeHolderObject,$insertedHolders[$item[

/**   } <-- **/
                    }
                    $blockObject->setPlaceholderValues($insertedHolders);
                    // output buffer the rendered frontend method of the block
                    $blockResponse = $blockObject->renderFrontend();

well that's my idea at the moment.

Further one could think of some communication between ChildBlocks/Parentblocks on cms-admin-side-of-things to assist things like:

• having a data model chosen in the FormBlock
• all child-InputBlocks obtain possible variable-names and types from Parent-FormBlock. (but well that's for later)

[nadar]

We where already thinking about this too, making drop ability for only a certain type of blocks.

I like the idea with the form a lot! Give me a few hours to think about how to implement.

What further came into my mind:

• We should make a luya-bootstrap4-formbuilder / luya-boostrap3-formbuilder repo which contains all kind of different form types with a "baseform" block which is the form itself
• baseform =
  {{ placeholder }}
• form types = which can be place in "baseform" (form) (selects, checkbox, etc.)
• as its bound to bootstrap 4 (for example) the ActiveForm and Assets would be loaded automatically, maybe in combination with luya-module-contact

[tskodaw]

That sounds nice. Actually with the form builder, one can easily build his own contact-form, there is no need for an extra contact-form-module ;) ...there could be different Form-Handler-Controllers from which to choose.

As for now I am using a DynamicModel, instantiated in the "base-form", left as a static class attribute of the FormBlock, and every InputBlock uses that model in that static attribute, with those mentioned onBeforeRender etc. functions this could be solved in a better way, just passing the DynamicModel-Object to the TextInputBlock-Object before it is rendered.

The base form could manage all the actions ( just a call to a choosable controller-class or something) and data preparations. As well as having the possibility to choose from a list of FormEnabledDataModel extends Model or a DynamicModel (first is perhaps good when certain demands on the data model are required to store it to the database, DynamicModel is cool for creating the Form in first place or just send data easily via E-Mail etc.)

The InputBlock-Fields can obtain selectable/configurable rule sets as well as design sets.

[luya-bot]

Issue moved to https://github.com/luyadev/luya-module-cms/issues/10