This issue has originally been reported by @tskodaw at luyadev/luya#1541.
Moved here by @nadar.
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:
![image](https://user-images.githubusercontent.com/15832362/31437902-3be478a2-ae87-11e7-8483-d640e6c98538.png)
on the page:
![image](https://user-images.githubusercontent.com/15832362/31438373-34cbb944-ae88-11e7-8afe-f52bf210a3a1.png)
(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:
![image](https://user-images.githubusercontent.com/15832362/31438335-1ae95414-ae88-11e7-9071-4b95a617ebb0.png)
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)