Team. For those of you who have the time and interest in developing and evangelizing JAVA technologies for the 8th Edition visit:
https://glassfish.java.net/adoptajsr/?elq_mid=19509&sh=17122328192691122150139523&cmid=WWMK15020783MPP039C002
There is currently a big push at Oracle for more community involvement. It is expected that JAVA 8 will have the most participation from rank-and-file engineers than any other release.
This link was available in the OTN Java Developer Newsletter - June 2015 which arrived in my inbox on the 18th of June.
The posts recently have been rather sparse since we have been preoccupied with other work. Everything happens at the right place and time. We will continue posting comments on the Early Draft of MVC 1.0 Ozark plus more on CABOOSE in future weeks.
Happy Coding...Hunt...Peck...Think...Be a Pensive Programmer...
Friday, June 26, 2015
Wednesday, June 17, 2015
A Summary of Section One of the Second Chapter on Oracle's Ozark MVC 1. 0 - Early Draft
The entire second chapter provides a concise summary and introduction for the three main components found in Oracle's Ozark product: the model, the view, and the controller. Oracle sets aside a section for each.
The components are addressed in order of importance and detail. The first and longest section is on controllers. The second on models, And, the last on views.
Section One of the Second Chapter : Controllers
A controller for an Oracle's MVC 1.0 architecture is a JAX-RS resources method annotated with "@Controller". One might make all of the resource methods in a JAX-RS service controllers by placing the "@Controller" annotation on the class representing all of the resources. Also, one can produce a hybrid JAX-RS webservice with a mixed of "@controller" annotated methods and regular resource methods.
The following is a definition of a simple "Hello World" controller:
//the "hello" controller method returns the path for a JSP resource.
@Path("hello")
public class HelloController {
@GET
@Controller
public String hello() {
return "hello.jsp";
}
}
Controller methods and the regular JAX-RS resource methods interpret the String return type differently. Controller methods see a String return type as a path for viewable instead of text content. A controller might might have one of four different return types: void which requires that the method be annotated with @View, String ( a path for view content ), Viewable which bundles information about a view and how it should be processed, and JAX-RS response whose entity type is any one of the aforementioned types. It should be noted that the default content-type returned by a controller is text/html unless one specifies differently using the @Produces annotation. Also, the "@View" annotation is only applicable for controller methods with a void return type. Although only four possible return types from controller methods are allowed, the parameters of such methods do not have any limitations other than any of those imposed on regular JAX-RS service methods. Also, like regular JAX-RS services, the default resource class instance is per-request. Despite this similarity with regular JAX-RS services, controllers must be CDI-managed beans. This includes any hybrid classes.
//The controller methods in this class are all equivalent
@Controller
@Path("hello")
public class HelloController {
@GET
@View("hello.jsp")
public void helloVoid() {
}
@GET
public String helloString() {
return("hello.jsp");
}
@GET
public Viewable hellowViewable() {
return new Viewable("hello.jsp");
}
@GET
public Response helloResponse() {
return Response.status(Response.Status.OK).entity("hello.jsp").build();
}
}
The summaries for the next couple of sections of this chapter will be coming later this week or next week. It seems that the 40+ hours of "fun" each week recently will continue for some time. This has limited the available effort on Saturdays. We will gradually adjust and hopefully resume our Monday,Wednesday, and Friday post.
Happy Coding. La-La.
The CABOOSE Team.
The components are addressed in order of importance and detail. The first and longest section is on controllers. The second on models, And, the last on views.
Section One of the Second Chapter : Controllers
A controller for an Oracle's MVC 1.0 architecture is a JAX-RS resources method annotated with "@Controller". One might make all of the resource methods in a JAX-RS service controllers by placing the "@Controller" annotation on the class representing all of the resources. Also, one can produce a hybrid JAX-RS webservice with a mixed of "@controller" annotated methods and regular resource methods.
The following is a definition of a simple "Hello World" controller:
//the "hello" controller method returns the path for a JSP resource.
@Path("hello")
public class HelloController {
@GET
@Controller
public String hello() {
return "hello.jsp";
}
}
Controller methods and the regular JAX-RS resource methods interpret the String return type differently. Controller methods see a String return type as a path for viewable instead of text content. A controller might might have one of four different return types: void which requires that the method be annotated with @View, String ( a path for view content ), Viewable which bundles information about a view and how it should be processed, and JAX-RS response whose entity type is any one of the aforementioned types. It should be noted that the default content-type returned by a controller is text/html unless one specifies differently using the @Produces annotation. Also, the "@View" annotation is only applicable for controller methods with a void return type. Although only four possible return types from controller methods are allowed, the parameters of such methods do not have any limitations other than any of those imposed on regular JAX-RS service methods. Also, like regular JAX-RS services, the default resource class instance is per-request. Despite this similarity with regular JAX-RS services, controllers must be CDI-managed beans. This includes any hybrid classes.
//The controller methods in this class are all equivalent
@Controller
@Path("hello")
public class HelloController {
@GET
@View("hello.jsp")
public void helloVoid() {
}
@GET
public String helloString() {
return("hello.jsp");
}
@GET
public Viewable hellowViewable() {
return new Viewable("hello.jsp");
}
@GET
public Response helloResponse() {
return Response.status(Response.Status.OK).entity("hello.jsp").build();
}
}
The summaries for the next couple of sections of this chapter will be coming later this week or next week. It seems that the 40+ hours of "fun" each week recently will continue for some time. This has limited the available effort on Saturdays. We will gradually adjust and hopefully resume our Monday,Wednesday, and Friday post.
Happy Coding. La-La.
The CABOOSE Team.
Saturday, June 6, 2015
Second Chapter Summary Coming | Continued Thoughts on a General-Purpose JSP/JSF Tag
Team,
The summary of the second chapter of Oracle's Early Draft Documentation for Ozark should be available by the middle of next week.
Some thoughts arose about the notes posted earlier in this blog which suggested the use of reflection with a custom JSP/F tag for invoking behavior from a method within a classes. Also, this can be done using expression language, #{fully.qualified.class.name.method(parameters,...)}. If an application can tolerate the overhead of reflection, all of the behavior needed for generating its necessary views is encapsulate-able in JAVA packages. This might be a reasonable alternative for "custom" tag support depending upon a development teams skills set. It places most of the JEE concerns in a single custom tag which is already written and tested. The tag is extensible through the creation of libraries for the support of HTML processing.
Another approach for achieving a similar result is the technique of "byte-code" injection which allows for weaving compiled instructions within the fabric of existing class code. This would remove the cost associated with reflection, dynamic invocation, found in the previous paragraph.
Simply a few thoughts for this weekend which might have some value. Some of which might have been repeated from earlier entries in the web history.
Enjoy This Weekend,
The CABOOSE Team.
The summary of the second chapter of Oracle's Early Draft Documentation for Ozark should be available by the middle of next week.
Some thoughts arose about the notes posted earlier in this blog which suggested the use of reflection with a custom JSP/F tag for invoking behavior from a method within a classes. Also, this can be done using expression language, #{fully.qualified.class.name.method(parameters,...)}. If an application can tolerate the overhead of reflection, all of the behavior needed for generating its necessary views is encapsulate-able in JAVA packages. This might be a reasonable alternative for "custom" tag support depending upon a development teams skills set. It places most of the JEE concerns in a single custom tag which is already written and tested. The tag is extensible through the creation of libraries for the support of HTML processing.
Another approach for achieving a similar result is the technique of "byte-code" injection which allows for weaving compiled instructions within the fabric of existing class code. This would remove the cost associated with reflection, dynamic invocation, found in the previous paragraph.
Simply a few thoughts for this weekend which might have some value. Some of which might have been repeated from earlier entries in the web history.
Enjoy This Weekend,
The CABOOSE Team.
Monday, June 1, 2015
The Final Notes for the First Chapter of the Early Draft of MVC 1.0 (Ozark)
Team. For those who are interested, Ozarks issue tracking
system for the first release is located at
https://java.net/jira/browse/MVC_SPEC, the API documentation is at
https://mvc-spec.java.net, and one can find the reference implementation at
https://ozark.java.net. After reading through part or most of the
documentation, you can provide the expert group with any inputs which are valuable by
mailingusers@mvc-spec.java.net.
For those who actual read through the early draft, they
should be aware that most of the terminology used comes from the JAX-RS and Context and Dependency Injection (CDI)
specifications. The following pairs of terms: per-request and request-scoped
plus per-application and application-scoped, are synonymous. Also, the
following terms should be interpreted as they are described in RFC 2119,
http://www.ietf.org/rfc/rfc2119.txt, "must", "must not",
"required", "shall", "shall not",
"should", "should not", "recommended",
"may", and "optional". Plus, all assertions are formatted
using a descriptive name plus a label and can be found in Appendix A of the
Early Draft. Also, all JAVA code fragments use a courier font and line
numbering. Uniform Resource Identifiers (URIs)n of the general form
"http://www.example.org" and "http://www.example.com" are
application or context-dependent URIs.
A summary of the second chapter will likely come during the
beginning of next week.
Enjoy a week of Enlightenment, Endeavor, and Success,
The CABOOSE Team
Subscribe to:
Posts (Atom)