Replies: 2 comments
-
Added overlay as well now, worked like expected. There is a OverlayController as secondary root controller. It need to be passed to any child controller which opens a popup. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Update: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
After a few iterations I think I found now a clean and simple model for organizing the UI layer.
Its a classical MVC model where the controller creates the view and the model. It passes itself and the model to the view. The model does not know about any of the other parts but can receive domain objects.
The controller is reacting to events from the view as well as other domain services or other controllers (e.g. navigation).
It calls methods on the model and might call services or other controllers. The controller is the backbone of the structure and builds a hierarchical graph.
The view is responsbile for creating, layouting and styling the compenents as well as passing user events to the controller. It use data binding (bi-directional should be avoided) to the model. It does not has any logic beside pure layout logic.
The model reflects the views state as bindable properties and is responsible for consistency of the data.
The model can extend an entity model from the presentation module (I used the term entity as reference to the DDD entity and to distinguish the model from the local model. This entity model is re-usable for other clients and frontends. Specific code can be kept in the local model.
Navigation is handled by controllers as well. There is no global navigation class anymore.
The JavaFX application is also treated like a view in a MVC group and the application gets launched via the JfxApplicationController. See https://github.com/chimp1984/misq/blob/master/desktop/src/main/java/misq/desktop/Desktop.java
For Views which are not part of the scene hierarchy like popups we will likely create a secondary graph (based on the child stage) but I have not worked on that yet.
The dependencies are passed to the controllers and models in form of the Api high level entry class for the sub domains. That way passing domain objects doesn't get a pain and we can avoid a DI framework.
I try to avoid a DI framework because it makes it too easy to add a dependency. If its hard to wire up manually a dependency it might be that this dependeny is not a right fit... But will see if we can stick with that, if we use a DI framework this approach with passing the Api reference can be replaced by injecting the actually needed dependency at the target. Acutally that approach with the Api does not feel really right after a second thought, but for now its ok I think....
Here is the offerbook implementation:
https://github.com/chimp1984/misq/tree/master/jfx/src/main/java/misq/jfx/main/content/offerbook
https://github.com/chimp1984/misq/blob/master/presentation/src/main/java/misq/presentation/offer/OfferbookEntity.java
Beta Was this translation helpful? Give feedback.
All reactions