RFC: Allow to define a dialog which will be shown on node creation

Creating Neos & Flow Code
21

First example implementation (WIP) of the PHP part:
https://review.typo3.org/#/c/41200/
It works completely independent from the wizard UI and can be used to automatically create child nodes for example. Still, there is already the possibility to pass action data to the controller that is made available in the EEL context when parsing the action’s options.

I forked the configuration format gist to reflect some changes during implementation. I can’t link it here, though, as new users are not allowed to paste more than one link in a post. :smile:

Feedback on both configuration and implementation is highly appreciated (it’s my first push to gerrit, thanks to @dimaip for his guidance :smile: )).

2 Likes
22

Here’s the link:

23

Status update: most stuff already works, but needs a lot more polish.
Still work in progress, see TODO.

This change is ready for preliminary testing and feedback: https://github.com/neos/neos-development-collection/pull/27

TODO:

  • Refactor validation. Currently it’s inside NodeSelection (!)
  • Fix CSS styling for some editors
  • Fix a few not working editors (Link, References etc)
  • Write tests for actionsOnNodeCreation (@theilm can you do it?)
  • Write documentation
  • Once PropertyConverterService is merged, setProperties action can be greatly simplified

Open questions:

  • How should the secondary editor open (e.g. for Media)? Currently it opens below modal and is unusable
  • Probably we should move editor configuration up one level for the consistency with the wizard and other places where editors may be used (properties.propertyName.ui.inspector.editorOptions -> `properties.propertyName.ui.editorOptions``). That would require some effort to make it B/C.
24

Could be done by a code migration that adjusts the YAML.

25

If you are interested in allowing complex forms, the basic form elements are rather simple:

Complex forms can be implemented with form elements that are rendered according to state variables, and that, upon form input changes, are able to update the state variables and trigger the re-rendering of the form.

If the state variables are implemented as query parameters, it is possible to directly link to a form in a specific state.

If javascript is enabled, the forms may only update specific blocks instead of the whole page. (ajax calls for the whole form or just dependend blocks.)

Multi-page wizards can be implented with an additional ?page= parameter, and form elements rendering only according to its value.

Think for example of a complex autocompleting node creation form with name, type, and parent node form elements: You enter a name, select a type, and the form updates to show only allowed nodes for the parent node. And if child nodes are to be created additional form elements appear to provide their node names.

?name=dim&parent=Yourcity&type=blog

If a “dimaip” blog already exists under “Yourcity”, the data base query done by the form element block for the name will get it and render a select box containing that name. The form element block for the “create blog” button may render the button only if ther is enough input data available, and render a “go to existing blog” button if the query returns a direct match.

Example implementation description: http://zenadmin.org/en/documentation/Wiki/page885.html

26

Hey @cgat, we already have the forms engine and form builder for frontend forms. The talk here is about the wizard inside Neos UI that is shown on node creation, to allow some input for back creating multiple nodes (e.g. upload multiple images and then create an image node with each image).
On the other hand, @christianm has introduced a very cool thing called depending properties, which we could also support in the wizard.