JSR371: MVC

JSR371: MVC

Administrator

Hello everyone,

During Javaland I made it to a short presentation on the MVC JSR (371). Any chance of future integration with it can be put to rest given that JSR-371 is an extension of the JSR that gave us JAX-RS, that is, it's web only. This JSR delivers a few annotations and interfaces, perhaps the ones that may look appealing to us are @Controller and @View (JavaEE already defines @Model http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html). It's funny how much JavaEE relies on annotations these days, instead of using interfaces or striking a balance between interfaces and annotations.

Given that we can't integrate with JSR-371 we are free to decide how to identify MVC members. I'd rather choose the interface approach instead of using annotations for marking such components, as interfaces allow us to define additional behavior/lifecycle that these components must deliver. Also, it doesn't force implementors to use a proxy/wrapper/delegate approach to handle MVC members (but allows them to make it so if they choose that option).

There was also a discussion at Javaland if we should restrict the API to explicit names such as "Controller", "Model", "View" and "MVCGroup" given that MVC is not the only game in town, there's MVP, MVVM and others. While it may be clear to us what we mean by MVC and that we can adapt the M, V, C to behave like their MVP, MVVM counterparts other people will simply stop at the name and get confused.

I'm partial to this point of view, as I can see some people getting confused but also favor clarity on intention.

Re: JSR371: MVC

I have one application that is based around some home made
framework for Business applications. It is Swing application for
users and business logic on Application server.

I'm working on this application/framework for more then 10 years
and I try when I have enough time to make little or bigger changes
in order to make my everyday life of supporting and developing
this application easier.

So reading all the discussions and comments here, I think how I
will apply all these ideas to my application/framework.

I like the idea of MVC. I know it is the way to go but I also have
lots of legacy code that mixes all elements of MVC in single class
without clear separation.

So I think it is important to have in mind the case when you have
to migrate lots of old code to new way of doing things. With this
framework should allow easy integration with legacy applications
in order to allow them to move parts of code step by step without
breaking the release cycle.

What you think about this?

Also some of my ideas or comments might sound stupid or crazy but
this is mostly because I always try to put new stuff trough my
experience and it is very limited.

As soon as I find how I can apply all these things in my code it
will be much easier for me to understand and make comments to the
discussions.

I hope I can help in the future with your work on this JSR.

have a nice day.

On 30.3.2015 г. 14:11 ч., aalmiray [via jsr377-api] wrote:

Hello everyone,

During Javaland I made it to a short presentation on the MVC JSR
(371). Any chance of future integration with it can be put to rest
given that JSR-371 is an extension of the JSR that gave us JAX-RS,
that is, it's web only. This JSR delivers a few annotations and
interfaces, perhaps the ones that may look appealing to us are
@Controller and @View (JavaEE already defines @Model http://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html).
It's funny how much JavaEE relies on annotations these days,
instead of using interfaces or striking a balance between
interfaces and annotations.

Given that we can't integrate with JSR-371 we are free to decide
how to identify MVC members. I'd rather choose the interface
approach instead of using annotations for marking such components,
as interfaces allow us to define additional behavior/lifecycle
that these components must deliver. Also, it doesn't force
implementors to use a proxy/wrapper/delegate approach to handle
MVC members (but allows them to make it so if they choose that
option).

There was also a discussion at Javaland if we should restrict the
API to explicit names such as "Controller", "Model", "View" and
"MVCGroup" given that MVC is not the only game in town, there's
MVP, MVVM and others. While it may be clear to us what we mean by
MVC and that we can adapt the M, V, C to behave like their MVP,
MVVM counterparts other people will simply stop at the name and
get confused.

I'm partial to this point of view, as I can see some people
getting confused but also favor clarity on intention.

Thoughts?

If you reply to this email, your
message will be added to the discussion below: