Team. We read the draft specification for the JCP's JSR 371 while working on CABOOSE over the weekend. Although this is rough draft, it is excellent! It incorporates and smoothly integrates the current features of JEE much better than CABOOSE in many ways. This is the main reason, we contacted the JCP in April of 2014 suggesting CABOOSE as a simplification of the current MVC products, Struts and Spring. We were certain that the resources at Oracle were better equipped for creating a flexible and powerful MVC than us. The controller for JSR 371 is represented by a JAX-RS web-service whose resources (methods) can supply view content using four possible return types: void, String, Viewable, or Resource. This provides greater flexibility in interfacing with JAVA resources such as servlets, Server Pages, and Faces (JSP and JSF) plus allows support for creating ViewEngines for rendering Viewable objects. We are currently deciding upon how we might weave the CABOOSE servlet in the MVC 1.0 and considering how it might augment the platform since one of the types that an JAX-RS controller might return is a String.
It seems that MVC 1.0 has a much easier learning curve that Struts or Spring. The concern partitioning is greatly improved! One can simply see where each view and its associated sub-concerns fit.
Also, upon reading the specification, it appears that CABOOSE should make better use of annotations. We really must spend the next few weeks reading the MVC 1.0 javadocs and some of the documentation for existing JEE packages. We have a presentation on CABOOSE scheduled at the local JUG in May. We will present some of the concepts from JSR 371 along with our working CABOOSE sample and ask for community feedback on how we might best integrate this project with the JSR.
If you would be interested in reading the specification, it can be found at:
https://jcp.org/aboutJava/communityprocess/edr/jsr371/index.html
The specification is about an hour's reading. It uses some acronyms which might be unfamiliar, but do a web search and you will find a brief definition for each. It is well written; I only noticed one typographical error.
Our work will never beat Oracle's. Their brain-trust is enormous and anything we can do they can do "meta" and faster. This does not mean that they used CABOOSE as a source of inspiration. That would be quite doubtful although a very cosmetic pattern similarity exists.
We sent Oracle an e-mail correspondence suggesting that they might consider presenting a few different approaches for developing a controller of this architecture in JAVA since someone might produce a extremely simple and popular answer for MVC 1.0. After reading the specification, it seems that this might be quite a challenge! JSR 371 definitely seems like it is a great approximation of the "best" solution and flexible enough that it can absorb any "upstart ideas".
Considering that JSR 371 builds its controller from a RESTful web-service instead of a servlet, a need might exist for the creation a more general-purpose MVC 1.0 controller which provides generic and parameterizable resources that return the types void, String, Viewable, and Resource. We might suggest this and see how well it is accepted among the Expert Group developing JSR 371. They might conclude that this would simply be more dynamic invocation than necessary. Or, they might like the idea of creating a reusable resource for the common case of development. The great benefit of this approach is that more than one developer can have his "hands" in the writing of a common controller at the same instance in time without the need for merging source modifications when done. Each would simply create his own class that provided the needed rendering methods that the controller would invoke dynamically based upon a mapping in XML which linked the rendering method with the RESTful webservice.
One of the developers who is part of JSR 1.0 has contributed a simple sample application using the MVC 1.0 product's draft packages. It is noted in the specification that the features of these libraries of classes might be different in the coming revisions of MVC 1.0.
It seems that we have some more work ahead of us: So we will continue our "birdie" algorithm... Hunt..Peck.Think...Happy Coding!
No comments:
Post a Comment