Team. We thought that we would compile some resources on the model-view-controller's use in common programming environments. Recently, we have mentioned Oracle's MVC 1.0 which is also JAVA Specification Request (JSR) 371 and currently under development. Plus, we have supplied a web-link with information on Microsoft's MVC product. This morning, we will re-post these. Plus, it does not appear that a dominant MVC implementation exists for PERL, PHP, or Python although a few examples are available on the web if one searches for "[THE_LANGUAGE_NAME] MVC" on Google, Yahoo, or Bing.
Oracle's MVC 1.0 (JSR 371)
https://jcp.org/en/jsr/detail?id=371
Microsoft's .NET MVC
http://www.asp.net/mvc
Microsoft's MVC Overview
https://msdn.microsoft.com/en-us/library/dd381412%28v=vs.108%29.aspx
Enjoy this day!
Monday, April 27, 2015
Wednesday, April 22, 2015
04.22.2014 | No Report
Team. There is not anything of significance that we can report this Wednesday. We attended a JAVA User Group last evening which covered Android programming. If you are interested in finding out more about JUGS and the topics covered in them, search for JAVA Users Group on YouTube. Some meetings are recorded.
Monday, April 20, 2015
JAVA Community Process (JCP) | JAVA Specification Request (JSR) 371 - MVC 1.0 | CABOOSE Implications
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!
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!
Friday, April 17, 2015
Notes on Halting, Contracts, and Concern | Plus, CABOOSE and Halt-ability
Team. On Wednesday, we reviewed a few ideas on how contracts can raise the "odds" of ensuring the halt-ability of an application. A few more notes are necessary for justifying this since it counters the "well-accepted" notion set forth by Goedel. As stated on Wednesday, a program will eventually "halt" with a correct or incorrect result if all of its contracts are correct. These contracts are represented by conditional guards placed at various point in the application, and they will "gracefully" halt the program if the state of the internal data ever ventures outside of its allowed bounds. Given that each of the contracts has been written properly, the program must eventually halt if its design requires this. Since the contracts represent a very small subset of the total number of code lines, one can focus on the correctness of these as a starting point in ensuring the correctness of the program.
Furthermore, if we assume that the probability of error in any given instruction is q, then the odds that c contracts are correct is POWER( ( 1-q ) , c ) using the Excel function for exponentiation. This is the result of the hyper-geometric distribution which describes how one determines the odds of s sequential events with a probability of p occurring. This total probability is simply p with an exponent of s. Now realizing that the probability of the remaining lines of code all being correct is POWER( (1 - q), (n-c) ) where n is much greater than c, one can insure halt-ability with a greater probability thorough the use of contracts.We should also mention that q must be less than 1.
Contracts as a Concerns
Contracts are fundamental concerns of any system whether they are actually formally addressed during its development or not.
CABOOSE and Halt-ability
The CABOOSE source contains a few explicit and implicit contracts in the form of conditional guards which measure the state of key variables. If the state of any of the monitored variables exceeds a boundary, an exception is raised. Will CABOOSE always halt? This is a excellent question. Considering that our original goal was simplicity and the code-base is less than a 0.5 KLOC, one will likely remember the earlier quote placed in this weblog that stated:
One can develop software in such a manner that it does not have any obvious errors or that it obviously does not have any errors.
In other words, it can be so incredibly "confusing" and "complex" that one cannot find any mistakes in it. Or, it can be so simple and well-written that any coding flaws jump off the page.
Our goal with CABOOSE is that flaws leap out of NetBeans when we read the source. Unfortunately, they have not always done so.
Enjoy this weekend....
Furthermore, if we assume that the probability of error in any given instruction is q, then the odds that c contracts are correct is POWER( ( 1-q ) , c ) using the Excel function for exponentiation. This is the result of the hyper-geometric distribution which describes how one determines the odds of s sequential events with a probability of p occurring. This total probability is simply p with an exponent of s. Now realizing that the probability of the remaining lines of code all being correct is POWER( (1 - q), (n-c) ) where n is much greater than c, one can insure halt-ability with a greater probability thorough the use of contracts.We should also mention that q must be less than 1.
Contracts as a Concerns
Contracts are fundamental concerns of any system whether they are actually formally addressed during its development or not.
CABOOSE and Halt-ability
The CABOOSE source contains a few explicit and implicit contracts in the form of conditional guards which measure the state of key variables. If the state of any of the monitored variables exceeds a boundary, an exception is raised. Will CABOOSE always halt? This is a excellent question. Considering that our original goal was simplicity and the code-base is less than a 0.5 KLOC, one will likely remember the earlier quote placed in this weblog that stated:
One can develop software in such a manner that it does not have any obvious errors or that it obviously does not have any errors.
In other words, it can be so incredibly "confusing" and "complex" that one cannot find any mistakes in it. Or, it can be so simple and well-written that any coding flaws jump off the page.
Our goal with CABOOSE is that flaws leap out of NetBeans when we read the source. Unfortunately, they have not always done so.
Enjoy this weekend....
Wednesday, April 15, 2015
Programming(Design) By Contract | Halt-ability
Team. This is short a note on contracts. For those of you unfamiliar with the concept of "programming by contract", we have included the following links which you can skim:
https://www.eiffel.com/values/design-by-contract/
http://en.wikipedia.org/wiki/Design_by_contract
This is very powerful technique. Consider, Goedel’s Halting Problem which argues that testing halt-ability is impossible. In other words, one cannot determine if a computer program which he has written will halt after it has started. Halt-ability is a fundamental question a programmer asks when he is checking the "correctness" of a program. Halt-ability does not guarantee "correctness", but is a pre-requirement for this in many cases.
Programming-by-contract can guarantee "halt-ability" of a program given that the source's contracts, a small subset of the instructions, are "correct". One achieves this goal by placing a contract in the form of a guard in front of important blocks of code. This guard is a conditional statement which checks the state of the programs key variables and ensures that they are in the appropriate ranges.
Given that the program receives correct input and each of the instructions of the program modifies this data correctly, the state of the program should have measurable bounds. If the data ever wanders outside these bound, one knows that the input was incorrect and the program might not halt on it. If the input was correct and its data reaches an out of bounds state, one can be certain that an error exists in the instructions, and the program might not halt. In either case, one can gracefully exit the program with an error digest. In which case, the program halts. Obviously, using contracts in the form of guards for ensuring halt-ability does not guarantee correctness since an "incorrect" instruction might modify data in such a way that it is not outside its value bounds but still is in error.
Contracts are a very powerful concept in computing and are not yet a buzzword among many professionals. One can represent the notion of a contract with many different computing structures besides conditionals. Abstractly put, a contract is an agreement between one region of a system and another. These contracts between the producer and the consumer of data can be explicitly or implicitly enforced. In fact, the requirement of javac that JAVA interfaces be fully defined represents the explicit enforcement of the contract between interface implementers and users.
Also, contracts are a rule used when programming and should be considered in design, but are not used in controlling the flow or accuracy of the design. So, design-by-contract would be more correctly called contractual design such as object-oriented design.
Zohar Manna wrote a wonderful text on program correctness in 1978 which is foundational for many of these concepts. Finding a copy is difficult, but it would be a great addition for any personal computing library.
Just a few notes. We should be working on the CABOOSE source this Saturday. Have a Great Day.
Monday, April 13, 2015
Saturday | 03.11.2015
Team. There was not any activity on the CABOOSE project this Saturday, the weekly workday. We will resume our progress on 03.17.2015 and will be placing the source text on-line for an informal code review in the coming days. You can make comments via the discussion forum at:
http://java.net/projects/caboose
Enjoy Your Day!
http://java.net/projects/caboose
Enjoy Your Day!
Friday, April 10, 2015
Oracle's MVC 1.0 | JCP JSR 371 | Markup-JAVA Translation (Just JSP/JSF)
Team.
Oracle's MVC 1.0 | JCP JSR 371
In April of 2014, we suggested that Oracle consider a JAVA Specification Request (JSR) which created a general purpose servlet for use as a controller in a "standard" MVC architecture. They considered it in one of the JCP Executive Committee meetings that Spring. Upon advice from a few JAVA Champions who attended the meeting, we started this open source project. The JAVA Community Process (JCP) Team stated that if there was enough interest in CABOOSE, they might consider it in the future; however, they felt that their current style of MVC using servlets and JSF was sufficient.
Our inquiry in the Spring of 2014, must have sparked some ideas in the JCP since they took a poll of the JAVA community and saw a need for a JSR addressing the most common architecture of web applications, the Type-II model-view-controller (MVC). They call this JSR MVC 1.0, and it can be found at jcp.org:
https://jcp.org/en/jsr/detail?id=371
If you find these pages on CABOOSE interesting, you should consider participating in the development of JSR 371. It would definitely be worth following. Also, consider joining the CABOOSE project at java.net.
JSR 371 uses servlets, JAVA Server Faces (JSF), and Actions in the description of an MVC. This style of MVC was developed from experiences with the Struts and Spring MVC. It might be labelled a Style-III MVC. Currently, among JEE MVC there are a pair of styles. Style-I, the oldest, used servlets and JSP as controllers, and Style-II uses servlets for the controllers and JSP/JSF for the view.
These "Styles" are commonly called "Types" which can be redundant and confusing when one discusses the original Type-I MVC which supports callbacks from the view and is commonly found in desktop applications and Type-II MVC which is "flatter", found on the web, and does not support view callbacks.
Also, please share what you like about CABOOSE with the JCP's JSR 371 team plus any enhancements which you might have conceived.
Also, it might be worth becoming conversant in Microsofts MVC 1.0 and learning from their successes and mistakes in its creation. The following is link is a starting point for discovering more:
http://www.microsoft.com/en-us/download/details.aspx?id=5388
MVC 1.0 was released in 2009 and likely is much like Struts and Spring with the notion of an "Action".
It is only Markup Translation
We have heard some complaints from a few young engineers that they do not really understand JSP and JSF. This would suggest that the CABOOSE approach might be an improvement in some ways over Style-II and III, Type-II MVCs. CABOOSE might be more intuitive, but JSP and JSF are a very powerful concept. When working with JSPs/JSFs, one should always remember that the markup is translated producing a JAVA servlet. So, a "choose/when" tag becomes a multi-way selection in JAVA such as a "switch" or "if-then-else ladder". And, a "foreach" becomes a "for" control structure.
Search the web for techniques that will provide the transliterated JAVA servlet source. Then, JSP/JSF will likely be more understandable.
This is a direct ("literal") translation and also called a "transliteration" among software engineers and computer scientist. In fact, we have only scratched the surface of using markup in the creation of "valid" computer programs and easing development for those who are language novices.
Markup languages simplify the development effort. Consider the difficulty of programming a graphical user interface on a desktop in the early 1990s versus creating an application with the same behavior using HTML plus the reusable widgets found in every browser. Anyone who can type is capable of creating a "simple" web page. Markup is easily learned.
At some point, it might be common that there is a markup for writing high-level language programs. Being text-based, this markup will likely be as simple as the "Lego-like" interfaces found in the experimental language Scratch @ MIT and Google's AppCreator.
So do not let JSP/JSF baffle you!
Have a Great Weekend.
Oracle's MVC 1.0 | JCP JSR 371
In April of 2014, we suggested that Oracle consider a JAVA Specification Request (JSR) which created a general purpose servlet for use as a controller in a "standard" MVC architecture. They considered it in one of the JCP Executive Committee meetings that Spring. Upon advice from a few JAVA Champions who attended the meeting, we started this open source project. The JAVA Community Process (JCP) Team stated that if there was enough interest in CABOOSE, they might consider it in the future; however, they felt that their current style of MVC using servlets and JSF was sufficient.
Our inquiry in the Spring of 2014, must have sparked some ideas in the JCP since they took a poll of the JAVA community and saw a need for a JSR addressing the most common architecture of web applications, the Type-II model-view-controller (MVC). They call this JSR MVC 1.0, and it can be found at jcp.org:
https://jcp.org/en/jsr/detail?id=371
If you find these pages on CABOOSE interesting, you should consider participating in the development of JSR 371. It would definitely be worth following. Also, consider joining the CABOOSE project at java.net.
JSR 371 uses servlets, JAVA Server Faces (JSF), and Actions in the description of an MVC. This style of MVC was developed from experiences with the Struts and Spring MVC. It might be labelled a Style-III MVC. Currently, among JEE MVC there are a pair of styles. Style-I, the oldest, used servlets and JSP as controllers, and Style-II uses servlets for the controllers and JSP/JSF for the view.
These "Styles" are commonly called "Types" which can be redundant and confusing when one discusses the original Type-I MVC which supports callbacks from the view and is commonly found in desktop applications and Type-II MVC which is "flatter", found on the web, and does not support view callbacks.
Also, please share what you like about CABOOSE with the JCP's JSR 371 team plus any enhancements which you might have conceived.
Also, it might be worth becoming conversant in Microsofts MVC 1.0 and learning from their successes and mistakes in its creation. The following is link is a starting point for discovering more:
http://www.microsoft.com/en-us/download/details.aspx?id=5388
MVC 1.0 was released in 2009 and likely is much like Struts and Spring with the notion of an "Action".
It is only Markup Translation
We have heard some complaints from a few young engineers that they do not really understand JSP and JSF. This would suggest that the CABOOSE approach might be an improvement in some ways over Style-II and III, Type-II MVCs. CABOOSE might be more intuitive, but JSP and JSF are a very powerful concept. When working with JSPs/JSFs, one should always remember that the markup is translated producing a JAVA servlet. So, a "choose/when" tag becomes a multi-way selection in JAVA such as a "switch" or "if-then-else ladder". And, a "foreach" becomes a "for" control structure.
Search the web for techniques that will provide the transliterated JAVA servlet source. Then, JSP/JSF will likely be more understandable.
This is a direct ("literal") translation and also called a "transliteration" among software engineers and computer scientist. In fact, we have only scratched the surface of using markup in the creation of "valid" computer programs and easing development for those who are language novices.
Markup languages simplify the development effort. Consider the difficulty of programming a graphical user interface on a desktop in the early 1990s versus creating an application with the same behavior using HTML plus the reusable widgets found in every browser. Anyone who can type is capable of creating a "simple" web page. Markup is easily learned.
At some point, it might be common that there is a markup for writing high-level language programs. Being text-based, this markup will likely be as simple as the "Lego-like" interfaces found in the experimental language Scratch @ MIT and Google's AppCreator.
So do not let JSP/JSF baffle you!
Have a Great Weekend.
Wednesday, April 8, 2015
Speeding Up A CABOOSE
Team. It has already been noted that the dynamic invocation used in CABOOSE for JEE might result in slower applications compared with servlets and JSPs/JSFs systems which have few if any reflective calls. If one is interested in spinning a CABOOSE which uses dynamic invocation and likely is the Bugatti Veyron of such systems, one should consider building in the fastest, compiled high-level language which he can find. This would likely be a C implementation.
Initially developed in the early 1970 at Bell Labs, C was the first highly "portable" language with compiler support on most, if not all, modern hardware platforms. C allows for dynamic invocation and has libraries for processing XML plus HTTP requests and responses. In benchmark test, C has performed nearly as well as assembly language code on average. This occurs because a C compiler can make certain optimizations which speed processing. Some of these include injecting in-line assembly language instructions.
In terms of the LAMP ports for CABOOSE, this form of invocation can be achieved when the interpreter evaluates a line of code, since the lines of code in the program can be dynamic. PERL, PHP, and Python are all interpreted languages which support this type of processing. The LAMP ports will likely be the "slowest" of the CABOOSE systems.
We do not have a C implementation in the current plans. It is not commonly used as a web scripting language and can seem somewhat cryptic for those who are not familiar with it. Also, seeing that C does not support objects the way that its offspring C++ does, using C would simply produce a controller application bundle (CAB). If one wants the object-orientation for the (OOSE) and the best speed, one should use C++.
With these notes about performance, it should be said that the CABOOSE for JEE should satisfy the normal case (95%) of development. This is also true of the CABOOSE for LAMP.
Hunt...Peck..Think..Have A Great DAy.
Initially developed in the early 1970 at Bell Labs, C was the first highly "portable" language with compiler support on most, if not all, modern hardware platforms. C allows for dynamic invocation and has libraries for processing XML plus HTTP requests and responses. In benchmark test, C has performed nearly as well as assembly language code on average. This occurs because a C compiler can make certain optimizations which speed processing. Some of these include injecting in-line assembly language instructions.
In terms of the LAMP ports for CABOOSE, this form of invocation can be achieved when the interpreter evaluates a line of code, since the lines of code in the program can be dynamic. PERL, PHP, and Python are all interpreted languages which support this type of processing. The LAMP ports will likely be the "slowest" of the CABOOSE systems.
We do not have a C implementation in the current plans. It is not commonly used as a web scripting language and can seem somewhat cryptic for those who are not familiar with it. Also, seeing that C does not support objects the way that its offspring C++ does, using C would simply produce a controller application bundle (CAB). If one wants the object-orientation for the (OOSE) and the best speed, one should use C++.
With these notes about performance, it should be said that the CABOOSE for JEE should satisfy the normal case (95%) of development. This is also true of the CABOOSE for LAMP.
Hunt...Peck..Think..Have A Great DAy.
Sunday, April 5, 2015
NetBean's Team Menu | Oracle's MVC 1.0
Team.We found a menu item under NetBean's Team menu that allows for the relocation of an Subversion project. We hope that this is all that we must use for placing the projects which we have in a local repositories online at java.net.
Also, we created the CABOOSE controller as an HTTPServlet project and will place it in a JAVA archive for use in your own projects. It will be placed on-line with a user's guide and accessible from java.net/project/caboose in the coming months.
We likely will not deliver an online post this Monday, but one will be available on Wednesday.
We were checking our SEO rankings for keywords such as "JAVA CABOOSE", "CABOOSE MVC", and etc. when we found an article outlining Oracle MVC 1.0 JSR started last summer. We joined the JAVA Community Process in 2013 and shared our desired for a CABOOSE-like MVC as a JSR in early 2014. I am not sure if this is what spawned the interest in creating the MVC 1.0 JSR based upon JAVA Server Faces and the lessons learned from Struts and Spring and their use of the Action concept.
For those of you who enjoy the simplicity of the CABOOSE MVC system, its XML configuration file describing each view and the user-defined replacement tiles, plus the use of dynamic invocation, consider joining the JCP and letting Oracle know what you enjoy about this project and MVC development strategy. After joining the JCP, also definitely join the CABOOSE project.
One can find out more about Oracle MVC 1.0 JSR at:
http://www.oracle.com/technetwork/articles/java/mvc-2280472.html
https://jcp.org/en/jsr/detail?id=371
Also, here is an older article which discusses Oracle's view on the MVC architecture in Standard Edition development:
http://www.oracle.com/technetwork/articles/javase/index-142890.html
For those of you who are celebrating a holiday this weekend, we hope that it has been a joyous few days. And whether or not you had a holiday over the past few days, enjoy the upcoming work week. Remember...Hunt...Peck...Think...Engineering is for the birds.
Also, we created the CABOOSE controller as an HTTPServlet project and will place it in a JAVA archive for use in your own projects. It will be placed on-line with a user's guide and accessible from java.net/project/caboose in the coming months.
We likely will not deliver an online post this Monday, but one will be available on Wednesday.
We were checking our SEO rankings for keywords such as "JAVA CABOOSE", "CABOOSE MVC", and etc. when we found an article outlining Oracle MVC 1.0 JSR started last summer. We joined the JAVA Community Process in 2013 and shared our desired for a CABOOSE-like MVC as a JSR in early 2014. I am not sure if this is what spawned the interest in creating the MVC 1.0 JSR based upon JAVA Server Faces and the lessons learned from Struts and Spring and their use of the Action concept.
For those of you who enjoy the simplicity of the CABOOSE MVC system, its XML configuration file describing each view and the user-defined replacement tiles, plus the use of dynamic invocation, consider joining the JCP and letting Oracle know what you enjoy about this project and MVC development strategy. After joining the JCP, also definitely join the CABOOSE project.
One can find out more about Oracle MVC 1.0 JSR at:
http://www.oracle.com/technetwork/articles/java/mvc-2280472.html
https://jcp.org/en/jsr/detail?id=371
Also, here is an older article which discusses Oracle's view on the MVC architecture in Standard Edition development:
http://www.oracle.com/technetwork/articles/javase/index-142890.html
For those of you who are celebrating a holiday this weekend, we hope that it has been a joyous few days. And whether or not you had a holiday over the past few days, enjoy the upcoming work week. Remember...Hunt...Peck...Think...Engineering is for the birds.
Friday, April 3, 2015
Custom JSP/JSF Tags With Dynamic Invocation (Reflection)
Team. We have posted some ideas on this before. In the future, the CABOOSE features will probably provide a general-purpose "custom" JSP/JSF tag. This almost sounds oxymoronic, a contradiction or clash of terms. How can something serve a general purpose and be customized at the same time?
Basically, we will create a "special-purpose" or "custom" tag which can invoke a method from any class which it is given. We will likely use programming-by-contract again and ensure that the method which the tag invokes accepts a string array as its only parameter (like the main method of a JAVA Standard Edition program).
It will likely take the following form:
<caboose:pin
class="mypackage.MyClass"
method="myMethod"
arguments="paramA,paramB,pramC" />
And, its method will return an HTML or XHTML string which replaces the tag.
As noted in the earlier documents on reflection, CABOOSE experiences a computational "cost" for its dynamic invocation. If these dynamic method calls were "hard-coded" in the source, certain optimizations could occur that would speed processing. Therefore, using CABOOSE requires slightly more computing cycles for accomplishing what one would if he "rolled his own" controller or custom tag each time. This is the trade-off for increased software reuse, reduced project cycle times, concurrent processing of developed task, and a reduced need for as much JAVA Enterprise Edition "know-how" on development teams among other benefits.
If you are interested in learning more about creating custom JSP/JSF tags, view:
http://www.tutorialspoint.com/jsp/jsp_custom_tags.htm
or
http://docs.oracle.com/cd/E11035_01/wls100/taglib/quickstart.html
This is a little more challenging:
http://docs.oracle.com/javaee/5/tutorial/doc/bnalk.html
Also, Murch provides an excellent text on JSP and Servlet Basics:
http://www.amazon.com/s/ref=nb_sb_noss_1/190-0002710-2917803?url=search-alias%3Daps&field-keywords=Murach+Servlets
For our newest viewers:
Милости Просим. Мы рады, что Вы находитесь здесь
That should say : Welcome. We are glad that your are here!
We hope that these thoughts have sparked some ideas for your own development efforts...Hunt.Peck.Think...Have a Great Weekend.
Basically, we will create a "special-purpose" or "custom" tag which can invoke a method from any class which it is given. We will likely use programming-by-contract again and ensure that the method which the tag invokes accepts a string array as its only parameter (like the main method of a JAVA Standard Edition program).
It will likely take the following form:
<caboose:pin
class="mypackage.MyClass"
method="myMethod"
arguments="paramA,paramB,pramC" />
And, its method will return an HTML or XHTML string which replaces the tag.
As noted in the earlier documents on reflection, CABOOSE experiences a computational "cost" for its dynamic invocation. If these dynamic method calls were "hard-coded" in the source, certain optimizations could occur that would speed processing. Therefore, using CABOOSE requires slightly more computing cycles for accomplishing what one would if he "rolled his own" controller or custom tag each time. This is the trade-off for increased software reuse, reduced project cycle times, concurrent processing of developed task, and a reduced need for as much JAVA Enterprise Edition "know-how" on development teams among other benefits.
If you are interested in learning more about creating custom JSP/JSF tags, view:
http://www.tutorialspoint.com/jsp/jsp_custom_tags.htm
or
http://docs.oracle.com/cd/E11035_01/wls100/taglib/quickstart.html
This is a little more challenging:
http://docs.oracle.com/javaee/5/tutorial/doc/bnalk.html
Also, Murch provides an excellent text on JSP and Servlet Basics:
http://www.amazon.com/s/ref=nb_sb_noss_1/190-0002710-2917803?url=search-alias%3Daps&field-keywords=Murach+Servlets
For our newest viewers:
Милости Просим. Мы рады, что Вы находитесь здесь
That should say : Welcome. We are glad that your are here!
We hope that these thoughts have sparked some ideas for your own development efforts...Hunt.Peck.Think...Have a Great Weekend.
Wednesday, April 1, 2015
Google Drive - Kernel and Servlet Source
Team. The current state of the kernel and generic servlet source will be placed in an Adobe file on Google Drive next week for your review. We are still working on getting the repository on-line. Eventually, these pair of classes will be placed in a archive called caboose.jar for use in developing model-view-controller applications with NetBeans and Eclipse. We will continue providing updates on our progress.
Subscribe to:
Posts (Atom)