Coming late to this discussion - I think a framework should not enforce any architecture because as all of you know people favor different design patterns so if you want people to adopt it they need to have the freedom to choose what better they like most.
On Mon, 2015-03-02 at 02:20 -0700, Tom Schindl [via jsr377-api] wrote:
> Coming late to this discussion - I think a framework should not
> enforce any architecture because as all of you know people favor
> different design patterns so if you want people to adopt it they need
> to have the freedom to choose what better they like most.
I don't really know, I don't think that would be a problem really.
The architecture would be "suggested" but not necessarily imposed, since
you have those lifecycle methods that handle specific aspect of
everything there is nothing that would prevent you for, say, from not
using MVC at all, and rather put a one big intermixed application into
the "running" phase, or take it from there and do your own patterns.
On the other end, a suggested architecture is a good thing, since it
helps standardise and concentrate on the task of implementing the
functionality rather than the boiler plate code of the architecture
As long as it is only a suggestion I'm fine but then it would be a lot better to concentrate the focus on the stuff this JSR is going to define and not on what pattern MVC, MVP, ... it should suggest to use. At least this is the way we worked on e4.
The only architecture pattern we require you to follow are the 2 very closely connected:
* IoC => Dependency Injection
* Service Pattern
The rest is up to you. You need to provide the DI container enough information to implement your preferred design pattern.
I think we can agree that we want an application written with JSR377's API to
- be able to define actions (behavior and properties such as icon, name, etc).
- be able to define views using the full fidelity of the chosen UI toolkit (i.e, no widget wrappers)
Following the MVC approach we've discussed so far
- Controllers define actions.
- Views can link actions to widgets.
- Controllers and Views communicate with each other via a Model.
The first implies that actions cannot exist without a controller, thought they may very well do so. E4 uses Command/CommandHandler without a direct controller associated with them. As a matter of fact I believe you can treat CommandHandlers in E4 as if they are mini-controllers on their own.
The second implies actions are accessible to the outside world given the right keys and/or mvc boundaries.
The third implies that controllers know no specific view and viceversa. This allows controllers and views to be tested independently from one another. Once can exchange implementations at any time too.
As tom said, a DI container and services are good enough to start but I wonder, are they the sole "architecture" requirements we can agree as the common denominator? Looking at the other source materials (besides E4) I'd say all of them follow MVC in one way or another.
- command/handler is the preferred pattern but it is not required in all areas!
- toolbar and Menu-Items can be associated directly with an action class without the intermediate step of a command in between, in contrast to that KeyBindings are required to use the command/handler framework which I think is most likely not ideal as it should have the same possibility as Toolbar/Menus have.
- The command/handler framework is context sensitive so e.g. you "could" (I don't say you should :-) reassign CTRL+N to different actions depending on the UI-context you are in. e.g. you are in then person table it creates a new person object, you are in a contracts table it creates a new contract, ... .
I bet Netbeans deals with it in the same way all I can describe and provide as input is how things are done in Eclipse RCP.