Related JIRA issue: MGNLUI-3576 - Getting issue details... STATUS
JIRA issue that could use the improved action: MGNLRES-186 - Getting issue details... STATUS
The problem
The pattern of a new resource creation action should look like this:
- Add resource actionbar action brings in a dialog.
- User specifies the name of a new resource.
- User saves the dialog.
- The new resource is created and the editor sub-app is automatically opened.
Possible quirks:
Main hurdle is that most of the 'hotfix'-type have to deal with two aspects of data - ResourceOrigin (on the higher level) and JCR (on the lower level).
- The new Resource Files app operates over simple
PropertySetItem's, whereas the actions usually want to do some JCR work and hence expectJcrNodeAdaptersas input (and also they output JCR-related information). - Resource Vaadin Item does not provide a link to the parent folder out of the box.
- Resource Files app will not react on the
ContentChangedEventcoming from JCR-related actions since the type of id's do not match (JcrItemIdwhen mere String paths expected). - JCR actions more or less easily operate with 'new'/transient items (
JcrNewNodeAdapter). However,JcrResourceOriginknows nothing of such items and will throw aResourceNotFoundExceptionupon any attempt to query such a resource. This makes it impossible to 'pre-create' a resource in JCR and work with it by means ofJcrResourceOrigin.
If we want to create a new resource in a 'usual' way trying to rely on just the existing actions:
A custom
CreateResourceActionunwraps the parent resource/folder and starts a dialog.- Dialog populates new resource properties into a PropertySetItem.
- Custom SaveResourceAction creates a resource entry in jcr and fires the callback
- The callback triggers the navigation to the new resource editor from the initial action (
CreateResourceAction).
Problems I see here:
- We have to add the parent path to the Vaadin item which we pass into dialog, so that when it saves - it knows where to create the new JCR node.
- When the saving is done - the initial action will have hard times resolving where to navigate because the new resource's path is not communicated back.
- We have to develop two custom, not really re-usable actions.
Possible alterations of this scenario:
- We resolve the parent JCR node in
CreateResourceActionand start dialog with an ad-hocJcrContentConnector:- We could then even delegate to
OpenCreateDialogAction,but:- it would create a new resource following the logic different from that defined in
ResourcesContentConnector#createNewResource - It would fire the
ContentChangedEventwith the item id type not treatable by Resource Files app. - it would still be problematic to navigate to the detail sub-app (??)
- it would create a new resource following the logic different from that defined in
- We could then even delegate to
Proposed solution
- As MGNLUI-3576 suggests - we introduce a new action called smth like
EditorCallbackActionin ui-framework which supersedes both the existingCallbackDialogAction/CallbackFormAction.- The semantics of the new action is the same - just notify the editor, that the detail sub-app/dialog finished editing the item without doing anything extra.
- The main difference from the aforementioned actions - it should also do validation to ensure the editing is correct.
- According to this all the resource-related logic happens within the
CreateResourceAction, the dialog action simply enclosed in it and only populates the properties like resource name, nothing else.- We end up writing only one custom action (which is sort of logically complete in terms that the full cycle of resource creation happens here).
- No need to pass around context information (e.g. parent coordinates, resulting resource path etc).
- Actual JCR entry creation is postponed till the latest action phase, cancel action stays as dumb as usually.
- Navigation is trivial since all the data is at the hand.

