Team. The CABOOSE site is currently a few static XHTML pages which have not been validated. If one examines these carefully, one will realize that the header and footer for each page are the same. The only unique content is in the body of the documents. This "primitive" content can be factored out of each page which will leave the base template. We can then supply this template and the appropriate body content when a browser requests that view.
In other words, the CABOOSE site is a good candidate for the model-view-controller (MVC) architecture. Unfortunately, the web hosting package for this site does not support JAVA Enterprise Edition development; however, it supports the LAMP technologies. So, we will spin a quick MVC for the CABOOSE site over the next week using the PHP Hypertext Processor (PHP). We already have the source since we used PHP as a prototyping language for the CABOOSE concept when we proposed a JAVA Specification Request (JSR) for a general-purpose web-script. We shared this PHP prototype with members of the JAVA Community Process(JCP) with a few instructions. Although not immediately accepted, the way in which CABOOSE project partition concerns creates a more cognitively accessible development approach. It also allows for a greater use of existing web standards.
The current PHP prototype is not highly robust; however, it is reliable enough for simple view handling. So, we will start making a few entries on our PHP CABOOSE weblog.
Have a Great Week.
The CABOOSE Team
Monday, November 30, 2015
Sunday, November 29, 2015
Website | CABOOSE
Team. This past weekend, we produced the first draft of a website for this JEE CABOOSE project. It can be found here. Take a quick tour of it. Constructive feedback is always welcome.
Happy Coding. Hunt...Peck...Think...!
The CABOOSE Team
Happy Coding. Hunt...Peck...Think...!
The CABOOSE Team
Tuesday, November 17, 2015
Where We Are At, Where We Have Been, and Where We Are Headed With CABOOSE.
Team. This is where we are at...
Over the past few weeks, we have created a short "hello" web application for Oracle's MVC 1.0 platform Ozark. We have also integrated Ozark with our CABOOSE source for producing a reusable controller which one might use for rapid application development. The source for each of these programs was placed online in the form of NetBeans archives. These are both worthwhile code objectives while preparing for Q3 2016 when Ozark will be ready for regular production use.
This is where we have been...
Around March 2014, we approached Oracle's JAVA Community Process (JCP) with a proposed JAVA Specification Request (JSR) for a reusable general-purpose servlet as a controller in Type-II MVC web applications. We were seeking an Oracle mentor with experience as a specification lead as a sounding board. After review among key members of the community, it was felt that JSP and JSF are sufficient for the time being. However, we were encouraged by the JCP and told that we should consider starting an open-source project for our servlet project. The JCP said that it would reconsider the JSR if the project gained enough support form the engineering community. So, this is what we have done. Between May 2014 and August 2014, Oracle polled the general JAVA engineering community asking if it would be interested in a MVC package. "Yes" was the response. Ozark began in September 2014. The code libraries for MVC 1.0 became available in March 2015. During October 2014, we started coding and working on this web-based development history. We started with a standard JAVA application project in NetBeans that would print "Hello...". We gradually evolved it, and it eventually became a reflection-based servlet that used an XHTML-template storyboard and string substitution for producing view specifications for a web browser. All of this source was placed in-line within the regular weblogs. We contemplated placing our local source repository online, but decided that this might be a little premature for our code product. Plus, we had some questions about any future limits which we might place upon ourselves by the repository administration choices we made. March through October 2015, included some "fun" times with other projects constraining our available effort. During these months, we posted a few notes about the notion of action-able data structures and how they might find a use in CABOOSE. A few missed documentation deliverables occurred during this period, but for the most part it was moderately productive.
This synopsis leaves us at where we are headed....
We have found that Ozark integrates well with CABOOSE, Controller Application Bundles for Object-Oriented Software Engineering. We could plug-in the reflective capabilities of CABOOSE in less than an hour, plus have realized that a JAX-RS web-service likely is a better choice for this functionality that a servlet. At best, they are equally valid locations for CABOOSE principles. Over the next few months, we must gather all of our documentation, create tutorials for CABOOSE with Ozark, and finish our JAVA archive which contains a CABOOSE-based ViewEngine and Servlet. Also, we must increase our online presence and continue building our community. We have had individuals from around the globe view these development notes. We have spoken at a local IEEE chapter on IEEE about Concern Partitioning and Organization which is at the core of CABOOSE. We have also received an informal request for another talk with a greater focus on CABOOSE in the future. We have also spoken at a local JAVA User's Group (JUG). We must increase awareness about this parallelized development approach for MVC applications.
Thank You For Your Interest And Support,
The CABOOSE Team
Over the past few weeks, we have created a short "hello" web application for Oracle's MVC 1.0 platform Ozark. We have also integrated Ozark with our CABOOSE source for producing a reusable controller which one might use for rapid application development. The source for each of these programs was placed online in the form of NetBeans archives. These are both worthwhile code objectives while preparing for Q3 2016 when Ozark will be ready for regular production use.
This is where we have been...
Around March 2014, we approached Oracle's JAVA Community Process (JCP) with a proposed JAVA Specification Request (JSR) for a reusable general-purpose servlet as a controller in Type-II MVC web applications. We were seeking an Oracle mentor with experience as a specification lead as a sounding board. After review among key members of the community, it was felt that JSP and JSF are sufficient for the time being. However, we were encouraged by the JCP and told that we should consider starting an open-source project for our servlet project. The JCP said that it would reconsider the JSR if the project gained enough support form the engineering community. So, this is what we have done. Between May 2014 and August 2014, Oracle polled the general JAVA engineering community asking if it would be interested in a MVC package. "Yes" was the response. Ozark began in September 2014. The code libraries for MVC 1.0 became available in March 2015. During October 2014, we started coding and working on this web-based development history. We started with a standard JAVA application project in NetBeans that would print "Hello...". We gradually evolved it, and it eventually became a reflection-based servlet that used an XHTML-template storyboard and string substitution for producing view specifications for a web browser. All of this source was placed in-line within the regular weblogs. We contemplated placing our local source repository online, but decided that this might be a little premature for our code product. Plus, we had some questions about any future limits which we might place upon ourselves by the repository administration choices we made. March through October 2015, included some "fun" times with other projects constraining our available effort. During these months, we posted a few notes about the notion of action-able data structures and how they might find a use in CABOOSE. A few missed documentation deliverables occurred during this period, but for the most part it was moderately productive.
This synopsis leaves us at where we are headed....
We have found that Ozark integrates well with CABOOSE, Controller Application Bundles for Object-Oriented Software Engineering. We could plug-in the reflective capabilities of CABOOSE in less than an hour, plus have realized that a JAX-RS web-service likely is a better choice for this functionality that a servlet. At best, they are equally valid locations for CABOOSE principles. Over the next few months, we must gather all of our documentation, create tutorials for CABOOSE with Ozark, and finish our JAVA archive which contains a CABOOSE-based ViewEngine and Servlet. Also, we must increase our online presence and continue building our community. We have had individuals from around the globe view these development notes. We have spoken at a local IEEE chapter on IEEE about Concern Partitioning and Organization which is at the core of CABOOSE. We have also received an informal request for another talk with a greater focus on CABOOSE in the future. We have also spoken at a local JAVA User's Group (JUG). We must increase awareness about this parallelized development approach for MVC applications.
Thank You For Your Interest And Support,
The CABOOSE Team
Saturday, November 7, 2015
Actionable Data Strutures and the New IF-THEN | Cogswell Cogs, Centipedes, And Stop Structures | CABOOSE Aside
Team. We are continuing our background reading on Bean Validation (BV), Context Dependency Injection (CDI), plus making another pass of the fundamentals in the JAVA Standard Edition Tutorial (https://docs.oracle.com/javase/tutorial/) for review.
Cogs from a Centipede
While doing this reading, some more thoughts on the possible behaviors for actionable data structures have arisen. We mentioned in an earlier note that a pair of cooperating circular queues could mimic a traditional for, while..do, or repeat..until structure without requiring any conditional branching and pipeline stalls. A pair of such cooperating queues would rotate upon one another like cogs in a mechanical timepiece. This would produce infinite repetition, and would likely be very rapid since it would not necessitate flushing the instruction pipeline on an erroneous branch prediction. Earlier, we labelled such a structure a centipede since the action of the data structure conjured up images of an 1980s video game of the same name.
Jane Stop This Crazy Thing
What we now need are stop structures. This is achievable with an actionable map whose get-key method results in the invocation of behavior. Such a map would hold a pair of action-sets associated with conditional truth values. On get( true-condition ) or on get( false-condition ), the resulting actions would permit the continuance of the iteration or halt it. Such a map would simulate an IF-THEN which always calculated the proper offset of the next action-set without branch prediction.
Buyer Beware
Much of these notions on Actionable Data Structures (ADS) are speculation with limited testing.
Enjoy This Upcoming Week. More will be coming in terms of CABOOSE source soon.
The CABOOSE Team.
Cogs from a Centipede
While doing this reading, some more thoughts on the possible behaviors for actionable data structures have arisen. We mentioned in an earlier note that a pair of cooperating circular queues could mimic a traditional for, while..do, or repeat..until structure without requiring any conditional branching and pipeline stalls. A pair of such cooperating queues would rotate upon one another like cogs in a mechanical timepiece. This would produce infinite repetition, and would likely be very rapid since it would not necessitate flushing the instruction pipeline on an erroneous branch prediction. Earlier, we labelled such a structure a centipede since the action of the data structure conjured up images of an 1980s video game of the same name.
Jane Stop This Crazy Thing
What we now need are stop structures. This is achievable with an actionable map whose get-key method results in the invocation of behavior. Such a map would hold a pair of action-sets associated with conditional truth values. On get( true-condition ) or on get( false-condition ), the resulting actions would permit the continuance of the iteration or halt it. Such a map would simulate an IF-THEN which always calculated the proper offset of the next action-set without branch prediction.
Buyer Beware
Much of these notions on Actionable Data Structures (ADS) are speculation with limited testing.
Enjoy This Upcoming Week. More will be coming in terms of CABOOSE source soon.
The CABOOSE Team.
Subscribe to:
Posts (Atom)