> The goal of this template is to remind you of many aspects that you could consider, to help you create a good concept.
> Tip: Use whichever sections are appropriate for the concept, delete the rest, rename and add at will, these are simply a suggestion.
> Tip: Delete all these comments.
Although messages are a platform thing the UI is heavily involved in displaying, dispatching and storing messages. It is clear that the UI framework should be concerned for the display and visualization of messages and notification but the UI should not be involved for dispatching and especially storing messages.
Here the call from the messages app as an example (apart from the Session all classes are part of ui-framework or message app):
MessagesViewImpl:sendButton → MessagesMainSubApp:handleGlobalMessage → AppInstanceControllerImpl:broadcastMessage → MessagesManagerImpl:broadcastMessage → :sendMessage → (MessageStore:saveMessage → Session.save() ; MessageManager:sendMessageSentEvent)
The reason is simple: Lets say we would like to develop a specific client for mobile devices (either a native app or a specific webapp) then we either had to depend on the vaadin based UI framework or reimplement everything for the other client which would lead to increased maintenance costs and failure rates.
Example Resource Creation
What should happen if a resource is created or overloaded is configured in a UI action. This includes:
- Finding the correct MediaType to set in the JCR properties
- Set the correct metadata in JCR like size, extension, mimetype, etc
- Set the modification date of this node
This functionality can't be reused by other systems other than admin central.
> AKA (Also known as): Starting Position
> Why is this concept being considered? What is the issue that someone is having that needs to be addressed?
We aim to separate the the UI from backend operations and both have business logic code separated and are JCR agnostic in the frontend.
Business logic like publication, uploading assets, change content (aka create new versions) or restore previous versions should be directly usable by many different users and not just admin central. REST endpoints is a good example or a new or specialized version of the UI.
Asynchronous behavior, which commands aim for, should be baked into the core and therefore its easier on the front end to provide long running functionality.
Change centric vs node centric
Actions and commands should focus on the full context of a change and not just on one node. Actions become more scalable through this and its easier to apply an action on multiple nodes in one go.
The following points are welcome side effects we try to achieve or automatically get but they don't have a main priority atm.
Through better separation both the business logic and frontend becomes easier to test and ideally many things we currently can only test with UI tests can be tested with just unit tests.
The action "Rename item" gathers the information which should change like: ID of the node to rename, new name, etc
The action handler dispatches the appropriate command with this we leave the user and client context
The central command handler will instantiate the correct command implementation and execute it
The command will do the things it should do. In this case find the correct JCR node and set the new name. Fire events for the changed states.
Command handler will make sure the events are forwarded to the correct users
Action handler will propagate the changes to the data sources
Update on the data source will cause the UI to update (It would be ok or even advisable to already update the UI before: that means the error cases have to be handled more carefully!)
Basically have the split of actions & commands like
Actions are the binding of front end specifics to a command. Actions together with the View Models () encapsulate the full lifecycle of data in the UI and handle both event dispatching and event handler for the data they are concerned. They do not implement business logic (at most they replicate or reuse it) and rely on the backend, through commands, on executing business logic.
Commands are user agnostic and can be used by an actual user interface like Admin Central or by a technical interface like REST or WebSockets. Commands encapsulate the steps behind state changes as well as side effects, like updating modification date or creating a new version, and communicating that changes to others.
> AKA: Rationale
> Pros and Cons
> Consequences of this approach.
- Calling User
With the use of completable future we could use the following pattern in the AddResourceAction e.g:
> Possible Improvements
> Discarded Proposals
This is related to the following JIRA issues:
DEV-818 - Getting issue details... STATUS
DEV-856 - Getting issue details... STATUS
MGNLUI-3398 - Getting issue details... STATUS
This topic is related to some degree to CQRS. Here some links for interesting read-ups: