JSR371: MVC

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

JSR371: MVC

aalmiray
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).

Thus, in terms of MVC I propose the following interfaces

  javax.application.mvc.Artifact:: defines base behavior such as init/destroy
  javax.application.mvc.Controller:: controller specific marker. Action methods annotated with @Action.
  javax.application.mvc.Model:: model specific marker.
  javax.application.mvc.View:: view specific marker. Defines methods for loading/building UI.

Adding from the previous discussion

  javax.applicaiton.mvc.MVCGroup

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?
Reply | Threaded
Open this post in threaded view
|

Re: JSR371: MVC

doychin
Hello everyone,

I'm reading all the posts in the last couple of months in this group.

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).

Thus, in terms of MVC I propose the following interfaces

  javax.application.mvc.Artifact:: defines base behavior such as init/destroy
  javax.application.mvc.Controller:: controller specific marker. Action methods annotated with @Action.
  javax.application.mvc.Model:: model specific marker.
  javax.application.mvc.View:: view specific marker. Defines methods for loading/building UI.

Adding from the previous discussion

  javax.applicaiton.mvc.MVCGroup

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:
http://jsr377-api.40747.n7.nabble.com/JSR371-MVC-tp149.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML


-- 
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
PowerStor - Warehouse & POS
http://www.dsoft-bg.com/
Mobile: +359888243116

doychin.vcf (280 bytes) Download Attachment