Moving to Java and Phobos

Sun Web Server 7 on Debian Lenny

2009-01-09T08:29:00.003-06:00

I recently built and deployed two more web servers using Debian Lenny and Sun Web Server 7. Although Debian is not specifically supported by Sun, the web server installs and runs flawlessly. With Java tightly integrated with the web server, deploying and maintaining Java applications is a breeze. This makes hosting web sites extremely simple even for the smallest companies. With the integrated WebDav and Java, the only thing you need besides the web server is a mail server. This makes maintenance and security tidier, and the learning curve is quite small compared to other web servers such as Apache and IIS. I have used all three and would hate to have to use anything else now. If you are curious, give it a try. It is free to download.

Phobos Version 0.6 Sun Web Server

2008-12-16T09:02:00.002-06:00

The latest version of Phobos is available at https://phobos.dev.java.net/v6/.

I have deployed the empty war app to both Sun GlassFish Enterprise Server v3 Prelude and Sun Java System Web Server 7.0 Update 3 successfully.

I hope to post more code samples soon!

Phobos Progress

2008-10-08T15:39:00.003-05:00

The Phobos team began working on the next version of Phobos. The details are located at https://phobos.dev.java.net/v6/index.html. Although progress has been slow, the improvements are well thought out and valuable. I have several code examples available for posting and hope to put them starting next month as time permits. I have a few basic pieces of a webmail app I am putting together using Phobos and JQuery. I will post the code for free use sometime this winter hopefully.

Phobos Production Apps

2008-06-17T15:26:00.002-05:00

Summer time is extremely busy for me and I do not get much chance to work with new technologies and projects. If only there were more hours in the day. . .

It amazes me how long it takes to bring technology on line in a business environment. I have been working with Phobos for a while now and looking for ways to implement it in production environments. It will happen in the future, but with economic and business cycles, it will take a few years to move into. Businesses first have to decide to move. Then they have to test and start with small projects. Then the pace begins to accelerate. This cycle of moving to something new can take years even if the new system is better. Meanwhile, people judge open source projects by the size of the communities and software running on it. Sometimes there are people using the software and working with it, but it is not visible to the world. It does takes time to write about what you are doing with a particular project, but it is a way of giving back to those who have worked on the project. I encourage others to write a blog or you can share what you are doing with someone who writes a blog. It will help to foster interest in a project.

Now if someone would pay me to write Phobos code . . .

Until then, I must regulate the fun stuff to off hours. :-)

JavaScript On The Wire

2008-04-30T21:18:00.001-05:00

I have been working on a website using Phobos, and it is interesting to
note some powerful features that are very subtle when using Phobos and
JavaScript in general compared to some other languages. One of these
features is what I have seen some call JavaScript on the Wire. This
means using JSON to transfer data around in your application. You can
read more about JSON at JSON.org. Now why is this powerful. In
JavaScript, it is powerful because JSON describes objects. Basically,
your data is described as an object, and you can pass it around to
different modules and functions without recreating it or destroying it.

To demonstrate, lets take a html form post. We can post that form to a
controller in Phobos. Inside that controller we can call a Phobos
library function to get our form field values with this line of code:

formFields = library.httpserver.parseRequestParameters();

formFields is now an object containing all of our form fields from our
html form. Let us suppose that we want to pass this on to a data
validation object which we have encapsulated as an object. We can do it
like this:

formFields = module.validateForm(formFields);

Now persist the data to the database with another module we have:

formFields = module.saveFormData(formFields);

Now use the model to pass the obeject back to the view to render the form:

model = formFields;

What we have just demonstrated is that we can take an object from some
input and pass it around all through our cycle of processing always
using the same object. Please do not forget that because we are using
JavaScript, we can add additional properties and methods to that object
anywhere in our cycle as well without affecting anything.

A good rule I have found is use to always pass data using JSON. This
not only makes coding easier, it also allows greater flexibility. If
you write a function which accepts one parameter it will get the job
done. However, if down the road you add a second parameter, now you
have some maintenance to do wherever that function is being called.
With JSON and passing objects, it doesn't matter. Just add a property
to the JSON object and the function doesn't care. It just accepts the
object with the extra property. Every other call to the function is
passing in an object with one less property. This rule makes for
flexible coding and less maintenance and broken code.

I am looking forward to see what will come out of Java One for Phobos,
although I will have to wait for the blogs and media as I am not able to
attend. While mostly using Phobos for web applications, I am interested
to see if Phobos will start up from the command line. Glassfish V3 has
options to run trimmed down, and light weight. If you can run Phobos in
a light weight Glassfish, it will open up some fun possibilities.
Because I do system maintenance, I can think of a few system scripts and
tools that would be nice to write in Phobos.

Phobos Most Important Feature - It Stacks Up

2008-04-11T09:32:00.004-05:00

I was recently asked, why did you choose Phobos? It made me stop and ponder all of the other scripting technologies I looked at, and why I settled on learning, developing, and writing about Phobos. Besides the requirement of being open source, here is my short list of importance.

1) It must be simple to use. Simplicity translates into more productivity.
2) It must be powerful. I do not want to reinvent the wheel for everything I need to
do.
3) It must be based on a somewhat standard deployment infrastructure. Some projects
are good at specific things, but once needs grow outside the original bounds, it
becomes difficult to meet advanced needs.
4) The language must be easy to use.

The best feature I find about Phobos is its simplicity. The way the infrastructure is laid out is incredibly simple, but powerful. There are minimum requirements to interface between the pieces, and yet the interfacing can be as complicated as you need it. You can abstract as much or as little as you want. Subclass as much or little as you want. Phobos is simple, but very flexible.

The second feature of being powerful. This is simplistic. You do not get more powerful than the Java platform. With Phobos, Java object integration is as native as Java. If your a Windows programmer, it is as native as using COM or .Net objects. When you look at large enterprise applications, a great majority are running on Java. This power is available to you as a script writer. With this integration, power, and Java market share, pieces can be dropped right into Phobos. For example, if you need to accomplish a certain task like make a connection to a database, you do not need to find a Phobos specific example on how to do it. You can take any basic Java example and rewrite it using JavaScript and the Java objects. This means that every piece of Java code on the Internet is now a Phobos example. If you stop and think about it, that thought is pretty incredible for a scripting language. We can conclude that in order to use Phobos effectively, we do not need millions of developers to have years of experience using it and writing examples of how to get things done, because we already have that. You can become very productive immediately.

Third. With the rapid pace of change in operating systems, servers, security and software, a solution based on a standard deployment platform is important. There are many good products out there, but if you invest years of development into an application, you want to be sure that it will run on the platforms of the future. Java containers and Java fill this need. They are standards based and deployed worldwide. Projects who maintain their own deployment infrastructure or app server, must change with the times. With deployment to a standard Java app server, we can be assured applications will run in the future.

Fourth. The language must be easy to use. I do not want to compare the pros and cons of different languages, but I will say that JavaScript is everywhere because of the Web. Many solutions are trying to give developers tools to avoid writing JavaScript. With a debuggers now available in NetBeans and in FireFox, why not just write JavaScript for web applications?

I recently saw an article touting Adobe's new AIR development server, DARE. It stated that this server would allow you to test AIR applications on your local machine. It would be as easy as changing a few lines of code and refreshing your browser. DARE will greatly increase web productivity and make it much easier to develop web applications. Is this really cutting edge? Is that what they are saying? We have had that with PHP and ASP for years. Anyway, I am not going to rant, but I will say that Phobos and Netbeans have this as well. No need for compile or deployment, just a browser refresh, and you do not have to use proprietary technology.

Phobos, DB Pooling And Connections

2008-03-27T21:48:00.001-05:00

For those who have followed my data examples in the past, and have tried
them out, here is a recent issue I ran across. I have designed what
some would call a data facad, crud module, business object. Whatever,
you want to call it, it handles all of the data access for a particular
table. I was testing this on my laptop from the Netbeans environment,
and every time a page was requested five times, the Phobos runtime would
go into an endless loop. However, when you stopped the run time, a null
pointer exception would be thrown on this line of code:

conn =
java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");

What this line does, is in my previous data examples. After doing some
checking around on Google about Java data pooling, it finally dawned on
me that I was running out of connections. I was closing the
connections, but the code was not getting executed. Here is an example
of the offending code in the module method which is called.

return obj;
stmt.close();
rset.close();
conn.close();

The code is never run, because execution stops at the return statement.
Some might think this would be obvious, but this behavior is not the
same in an ejs file or controller. My assumption was that it would get
run, and so we should get the data back asap. We could the worry about
cleanup code. However, all cleanup code needs to be run before the
return statement. It should look like this.

stmt.close();
rset.close();
conn.close();
return obj;

Small change, but big results. If we abstract our data access into
modules, it is fast and easy to clean this up versus having it scattered
in scripts.
Below is an example of a method of the crud class. I will hopefully be
posting all of the code for the data layer soon.

Happy Coding!

var stmt = null;
var rset = null;
var strSql = null;
// oConn is the connection pool set in application startup
conn =
java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");
strSql = 'SELECT * FROM article WHERE ARTICLE_PK = ?';
stmt = conn.prepareStatement(strSql);
stmt.setInt(1, articleId); // articleId is passed in
rset = stmt.executeQuery();
// Call method used to generate a json object of record set
obj = this.generateJson(rset);
obj.status = true;
stmt.close();
rset.close();
conn.close(); //clean up
return obj;

Sun Webserver on Debian

2008-03-15T20:47:00.001-05:00

Recently I needed to put together a web server for a few websites. The
hardware was put together on the cheap. It is amazing what you can get
with a few hundred dollars. The hardware consisted of a MSI motherboard
with an AMD dual core processor, two gig of ram and two sata hard
drives. All the hardware came in under $450.00. I installed the latest
version of the AMD64 Debian to run a headless system with software raid
1. I then installed Sun's web server which is available for free
without support. It also comes with 64 bit support for the AMD
processor. The only wrinkle I ran into during the install was that the
JDK that comes with the installation of the web server will not install
on Debian because of missing libraries. I worked around this by
installing the latest JDK from the Debian repository. I am using the
stable version so I did use apt pinning to pull that from the unstable
branch as some libraries are needed that are not in the stable branch.
I also installed Postgres 8.3 this way. Other than that, the install of
the web server went flawless. The start and stop scripts even appeared
to start the web server on system boot which was very nice, especially
since Debian is not officially supported by Sun.

After the install, web server maintenance was a breeze. I needed to
setup a few virtual hosts and I wanted them to be ip based. It took all
of about three minutes through the web interface. I looked at the Sun
web server a few years back and found the web interface to be somewhat
confusing. However, they have since redone the whole interface and it
is much more intuitive and straight forward. I found it very easy to
work with.

The web server also supports webdav out of the box. I decided to try
to allow users to change their files using webdav instead of setting up
an ftp server. This would trim one running process and also be one less
security detail to lock down. The webdav was easy enough to set up, but
I did have a slight problem getting the security to work properly.
However, a short trip to the Sun web server forum, where I received
several helpful answers almost immediately, solved the issue.

I chose to try Sun's web server over Apache because not being a long
time Linux guru, and needing extremely tight security on web systems in
todays environment, I felt much more comfortable with Sun's server.
With Apache, set up can be quite complicated and, in my opinion, it is
much easier to accidentally open up a security hole. It is too bad
Sun's marketing material bills the web server as best used for medium to
large installations, because it will work just as well for a small company.

One other thing I wanted to mention was what I was very impressed with
the speed of the server. It is fast at serving content up. I do not
claim to have benchmarks and what not, but coming from 32 bit hardware
and operating systems running IIS and SQL server, I was impressed. I am
sure it was a combination of the Linux kernel optimized for the
processor and then the web server optimized for the 64 bit chip, but the
speed is impressive nonetheless.

On a different note, when time permits, I will be trying out running a
Phobos app on Sun's web server. The web server is convenient over the
application server in the fact that it binds to port 80 and runs out of
the box as user nobody and has lots of virtual hosting tools. You can
use Glassfish to do the same thing, but of course it is not geared as
much for that purpose. Phobos could take the place of say asp or php on
a web server for a web host. A company could advertise web hosting
with server side javascript enabled out of the box with an open source
database.

I am happy to see Sun accepting the model they have for software as far
as licensing and support. Even though small companies may never want to
pay what a Sun support contract would cost them, I have found the Sun
employees on the forums to be most helpful. The more system admins and
developers that can use the software, the bigger ecosystem of free
support will be available out there on the web free of charge for small
users. With software, the better products doesn't always necessarily
win, it is the product that develops the largest user base for one
reason or another. Profits understandably must made, but is uncanny how
sometimes that profit will kill the product in the long run because
another product become more popular. I believe Sun is heading in the
right direction as far as growing their user base for their products and
I am happy to see it. Now if we could only get Solaris to run on dirt
cheap hardware . . .

Phobos Code and Java

2008-02-20T20:58:00.001-06:00

I have been working on a site recently and doing some more with data
access. I was working on the problem of creating multiple records in
different data sources and having to combine them at a later date. I
also wanted a generic way to insert a record and get the record back
without having to try to get an auto-generated key back from different
drivers and databases. This of course led to the idea that I needed a
unique number. What is the best way to do this inside of Phobos? You
first might think of someway to do it in Javascript, but this is where
we would be wrong. This is where the prowess of the Java platform comes
in. We tap the power of Java from our scripting language to do some
heavy lifting for us. So how much code does it take?

key = java.util.UUID.randomUUID().toString();

That's it! Now it may not be as random as a GUID, but it will work for
almost all situations, especially on small projects. We just tap a Java
class to accomplish this for us. There are other Javascript server
applications out there, but with the Java underpinnings, Phobos is hard
to beat.

More Phobos Data Access

2008-01-23T21:53:00.001-06:00

A few months ago I was playing with some data access code and thought I
would publish it. One of the problems some people must solve is data
access to sources without a jdbc driver. I used Phobos to connect to a
Visual Foxpro database. The same technique should be able to be used
for an Access database or other data. The first example just shows a
driver connection. The second example shows a pooled connection using
Apache Commons. The module code for the pooling part is in a previous
blog. This means you can have a pooled data connection from Phobos to
just about any data source. This would not be possible with most Java
application servers, but since we are using our pooling objects provided
by Apache, we can accomplish a much greater variety of data access from
Phobos. Phobos is versatile and flexible.

Driver Example:
library.common.define(controller, "test", function() {
this.Test = function() {
this.onRequest = function() {

// Set up our connection by specifying the driver
java.sql.Class.forName="sun.jdbc.odbc.JdbcOdbcDriver";
// We are using the java odbc bridge with a VFP database
// You need a DSN set up on your machine and for VFP you
// only need to specify the DSN name. User & Pass are blank.
var con = new
java.sql.DriverManager.getConnection("jdbc:odbc:javafox","","");
// create a statement
stmt = con.createStatement();
stmt.setMaxRows(1);
// create the result set by executing the query
// You can specify properties for locking etc if you wish.
rs = stmt.executeQuery("select * from some table");
//Loop through the result set and make a json object

// Close the connection.
con.close();

}; // End on request function
};
});

Pooled Example:

response.setStatus(200);
response.setContentType("text/html");
writer = response.getWriter();
writer.println("<html><head><title>Phobos</title></head><body>");

var conn = null;
var stmt = null;
var rset = null;
// custom module for pooled connection - start pool (normally done in
startup)
module.vfpDB.startConnectionPool();

writer.println("Pool Started<br>");
writer.println("Creating connection.<br>");
conn =
java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");
writer.println("Creating statement.<br>");
var stmt = conn.createStatement();
writer.println("Executing statement.<br>");
rset = stmt.executeQuery('select * from some table);
writer.println("Results:<br>");
var numcols = rset.getMetaData().getColumnCount();
while (rset.next()) {
for(i=1;i<=numcols;i++) {
writer.println("<br>" + rset.getString(i));
}
}
writer.println("Closing Pool.<br>");
module.vfpDB.closeConnectionPool();

writer.println("</body></html>");
writer.flush();

2008-01-01T19:44:00.000-06:00

With the arrival of the holidays and some time off, I was able to spend some time coding on my personal Phobos project. The fourth quarter months were so busy, I was not able to devote much time to coding. I have developed a starter web site, but wanted to develop a simple CMS to make it easy to make additions to the site. I have integrated the open source FCK editor and laid most of the groundwork. I am in the process of working out the bugs now. Instead of posting code samples, I hope to post all of the source code and maybe even a project file. I am pursuing it as time permits.

On another note, on a work related project, I have had to review a large amount of shopping cart software for selection for a new site. The languages covered were Java, PHP and .Net. One of the big requirements was the ability to get data in and out of the system easily in real time for integration into other business systems. After that, there was a need for a large amount of shopping features. Access to source code was also a must have feature whether it be open source or closed source. The system also needed to be somewhat economical for small business.

The two main Java options seemed to be KonaKart and SoftSlate. The KonaKart integration looked promising and the shopping system had plenty of features, but while it is free, they do not release the source code for their server side application. SoftSlate is an economical package with access to source code, but they do not expose web services and from what information I could gather, you would need to write your own integration code for external connections.

There were many php carts out there such as osCommerce, ZenCart and X-Cart. All of these are powerful, feature rich systems. Most of the integration features however consisted of importing data from a text file. While this is nice for total web based applications, it does not fare well interconnecting different business systems. Unfortunately, there wasn't much in the way of documentation as to how to get data in and out of these systems. It would be easy enough to write your own code, but on a complicated system, you wouldn't expect to write data directly to tables without having clear instructions on what data needs to go where. Many of the php carts say that they are working on data and layer abstractions.

I reviewed a few dotnet systems and the one that seemed to shine was AspDotNetStorefront. It was reasonably priced, you have access to source code and external integration in real time is extensive. It is based on proprietary technology, but it does provide advanced features, integration, and source code.

Out of the systems reviewed, it was interesting that depending on the language used, greatly affected the ability of others to work with a complicated system created by someone else. Most Java programmers abstract data access and other tasks. The object oriented nature of Java forces you to do this. The same principle would apply somewhat with dotnet. With PHP and Classic ASP, nothing is abstracted and the code is very free flowing. The nature of these languages make it quick to get stuff done, but as a system gets complicated, maintenance can become difficult. It also makes it much harder for someone who is not familiar with the system to come in and be productive because there isn't a built in blue print. Obviously there are exceptions to all rules because everything is still programmer dependent.

How does this affect Phobos? JavaScript is a very free flowing language and you can get things done very quickly with it. However, the Phobos architecture lends itself to write blue printed code. I think you can have the best of both worlds with Phobos. Of course this can be done in PHP now that it is object oriented as well as other languages, but the only language still that runs in the browser natively is JavaScript.

I think there is still room for a good open source shopping cart out there as well as simple CMS systems. The web is constantly changing and integration is becoming key. I believe Phobos fits the bill for small and large applications. Simplicity backed by the power of the Java infrastructure.

Phobos and System Admin

2007-11-06T08:38:00.000-06:00

Looking to move to Java and open source platforms and being a system admin, I have been working on setting up a public facing open source server. Although Phobos is a small part of that, it is a task that has to be learned and done if Phobos and Java are going to be the back bone of your web site. I find Linux and Java application servers more secure and easier to tune for specific security tasks, but the software still has to be learned and mastered. Running a Linux internal server is quite a different task than running an external server. Securing a server from the operating system up through the application is a real task with today's Internet. I am currently using a headless Debian server and Sun Application Server. I would love to try Solaris as soon as they have drivers available for a wider variety of hardware.

I am getting close to completion and hope to be running a beta site soon built entirely on Phobos. I like to see new technologies and I am excited about Phobos. My goal is to help build a larger community committed to Phobos with the site. When I see a web technology, I always like to see what the people recommending it are doing with it and if they are actually running it themselves. Sure, you can use many tools that may be more automated and built for you for running a web site or application, but if a foundational technology is going to become popular, ready made pieces must be built using it. Therefore, everything on the site will be built using Phobos and Java.

I will be soliciting for volunteers to help and contribute code for pieces of the site as I can only devote so much time to the project. My goal will be to build a community driven site with many contributors of examples as well as code for the web site.

Watch this blog for the release site which will be coming soon.

Phobos Data Access

2007-10-18T13:16:00.000-05:00

Previously I had posted an example for setting up a database connection pool using Apache commons. I have rough drafted an application module and a sample script to use it. We still need logging and a few other things in the module, but it is a start. We could also develop module and properties for other information in the pool.

Here is the script to use the module.


   1:response.setStatus(200);
   2:response.setContentType("text/html");
   3:writer = response.getWriter();
   4:writer.println("<html><head><title>Phobos</title></head><body>");
   5:
   6:var conn = null;
   7:var stmt = null;
   8:var rset = null;
   9:if (globals.oConnRunning) {
  10:   writer.println("Pool Running.<br>");
  11:}
  12:
  13:writer.println("Creating connection.<br>");
  14:conn = java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:oConn");
  15:writer.println("Creating statement.<br>");
  16:var stmt = conn.createStatement();
  17:writer.println("Executing statement.<br>");
  18:rset = stmt.executeQuery('Select * from customer');
  19:writer.println("Results:<br>");
  20:var numcols = rset.getMetaData().getColumnCount();
  21:while (rset.next()) {
  22:    for(i=1;i<=numcols;i++) {
  23:        writer.println("<br>" + rset.getString(i));
  24:    }
  25:}
  26:
  27:writer.println(module.dbu.statsConnectionPool()+"<br>");
  28:writer.println("Closing Pool.<br>");
  29:module.dbu.closeConnectionPool();
  30:if (globals.oConnRunning==false) {
  31:   writer.println("Pool Stopped.<br>");
  32:}
  33:writer.println("</body></html>");
  34:writer.flush();

Here is a the module.


   1:library.common.define(module, "dbu", function() {

   2:    // used to start connection pool
   3:    this.startConnectionPool = function() {

   4:      try {
   5:         java.lang.Class.forName("org.apache.derby.jdbc.ClientDriver");

   6:        // First, we'll need a ObjectPool that serves as the actual pool of connections.

   7:        var connectionPool = new Packages.org.apache.commons.pool.impl.GenericObjectPool();

   8:        // Set up our connect string for our database

   9:        var connectURI = 'jdbc:derby://localhost:1527/sample;user=app;password=app';
  10:        // Next, we'll create a ConnectionFactory that the pool will use to create Connections.

  11:        // We'll use the DriverManagerConnectionFactory
  12:        connectionFactory = new Packages.org.apache.commons.dbcp.DriverManagerConnectionFactory(connectURI,null);

  13:        // Now we'll create the PoolableConnectionFactory, which wraps

  14:        // the "real" Connections created by the ConnectionFactory with

  15:        // the classes that implement the pooling functionality.

  16:        poolableConnectionFactory = new Packages.org.apache.commons.dbcp.PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,true);

  17:        // Finally, we create the PoolingDriver itself

  18:        java.lang.Class.forName("org.apache.commons.dbcp.PoolingDriver");
  19:        // ...and register our pool with it.

  20:        var driver = java.sql.DriverManager.getDriver("jdbc:apache:commons:dbcp:");

  21:        // Now we can just use the connect string "jdbc:apache:commons:dbcp:example"

  22:        // to access our pool of Connections.

  23:        driver.registerPool("oConn",connectionPool);
  24:        globals.oConnRunning = true;

  25:        return true;
  26:      }
  27:      catch(exception) {

  28:        globals.oConnRunning = false;
  29:        return false;

  30:      }     
  31:    }// startConnectionPool
  32:
  33:    // Close the connection pool

  34:    this.closeConnectionPool = function() {
  35:      try {

  36:        var driver = java.sql.DriverManager.getDriver("jdbc:apache:commons:dbcp:");

  37:        driver.closePool("oConn");
  38:        globals.oConnRunning = false;

  39:        return true;
  40:      }
  41:      catch(exception) {

  42:        return false;
  43:      }
  44:    }// Close connection pool

  45:
  46:    // Connection pool stats
  47:      //Returns number active and idle in format active,idle eg 3,10

  48:    this.statsConnectionPool = function() {
  49:        var driver = java.sql.DriverManager.getDriver("jdbc:apache:commons:dbcp:");

  50:        connectionPool = driver.getConnectionPool("oConn");
  51:        var stats = connectionPool.getNumActive() + "," + connectionPool.getNumIdle();

  52:        return stats;
  53:    }//stats connection Pool

  54:});
  55:

Phobos - Database - Apache Commons

2007-10-04T09:17:00.000-05:00

I have been playing with data access from Phobos for some time now and was looking for a data solution with the following objectives in mind.

1) Data Pooling and Caching should be done within Phobos. This will make a Phobos application application server agnostic. There would be no extra application server configuration.

2) It should be fairly easy to use multiple databases from different vendors or projects.

3) You should be able to control the process all the way down to the connection from Phobos, but also be able to abstract access so pieces of the application do not need to know about the connection.

4) The solution should be simple. The end goal is for a basic web application. For large, enterprise applications, a custom application server specific solution can be achieved easily by an IT department.

After some research, I decided to try the Apache Commons components for database caching. I used a Java connection pooling example and converted it to a Phobos script to do essentially the same thing using the same Java objects. I have tested it and have it working with Derby and the app database included with Netbeans 6.0.

The next step would be to put the data access code in a Phobos module to abstract the database access and include some utility methods as well as error trapping.

I also would like to mention how easy this process was. I am not a Java programmer. I have read some books and written some basic programs, but would not consider myself fluent in Java by any means. However, using Javascript and Phobos, you can utilize the power of these Java objects rather easily.

*******************************************************************

Here is the Phobos script:

// This will set up our writer.
// We could do this with a dynamic script or view as well
response.setStatus(200);
response.setContentType("text/html");
writer = response.getWriter();
writer.println("<html><head><title>Hello</title></head><body>")

// Set up our connection by specifying the driver
java.lang.Class.forName("org.apache.derby.jdbc.ClientDriver");

// First, we'll need a ObjectPool that serves as the actual pool of connections.
var connectionPool = new Packages.org.apache.commons.pool.impl.GenericObjectPool();

// Set up our connect string for our database
var connectURI = 'jdbc:derby://localhost:1527/sample;user=app;password=app';

// Next, we'll create a ConnectionFactory that the pool will use to create Connections.
// We'll use the DriverManagerConnectionFactory
connectionFactory = new Packages.org.apache.commons.dbcp.DriverManagerConnectionFactory(connectURI,null);

// Now we'll create the PoolableConnectionFactory, which wraps
// the "real" Connections created by the ConnectionFactory with
// the classes that implement the pooling functionality.
poolableConnectionFactory = new Packages.org.apache.commons.dbcp.PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,true);

// Finally, we create the PoolingDriver itself
java.lang.Class.forName("org.apache.commons.dbcp.PoolingDriver");

// ...and register our pool with it.
driver = java.sql.DriverManager.getDriver("jdbc:apache:commons:dbcp:");

// Now we can just use the connect string "jdbc:apache:commons:dbcp:example"
// to access our pool of Connections.
driver.registerPool("example",connectionPool);
// This is the end of the setup code

// Now, we can use JDBC as we normally would.
// Using the connect string
// jdbc:apache:commons:dbcp:example
// The general form being:
// jdbc:apache:commons:dbcp:<name-of-pool>
var conn = null;
var stmt = null;
var rset = null;

writer.println("Creating connection.<br>");
conn = java.sql.DriverManager.getConnection("jdbc:apache:commons:dbcp:example");
writer.println("Creating statement.<br>");
var stmt = conn.createStatement();
writer.println("Executing statement.<br>");
rset = stmt.executeQuery('Select * from customer');
writer.println("Results:<br>");
var numcols = rset.getMetaData().getColumnCount();
while (rset.next()) {
for(i=1;i<=numcols;i++) {
writer.println("<br>" + rset.getString(i));
}
}
writer.println("</body></html>");
writer.flush();

*********************************************************************************

Here is the Apache Commons example:

/*
* Copyright 1999-2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.Statement;
import java.sql.ResultSet;
import java.sql.SQLException;

//
// Here are the dbcp-specific classes.
// Note that they are only used in the setupDriver
// method. In normal use, your classes interact
// only with the standard JDBC API
//
import org.apache.commons.pool.ObjectPool;
import org.apache.commons.pool.impl.GenericObjectPool;
import org.apache.commons.dbcp.ConnectionFactory;
import org.apache.commons.dbcp.PoolingDriver;
import org.apache.commons.dbcp.PoolableConnectionFactory;
import org.apache.commons.dbcp.DriverManagerConnectionFactory;

//
// Here's a simple example of how to use the PoolingDriver.
// In this example, we'll construct the PoolingDriver manually,
// just to show how the pieces fit together, but you could also
// configure it using an external conifguration file in
// JOCL format (and eventually Digester).
//

//
// To compile this example, you'll want:
// * commons-pool.jar
// * commons-dbcp.jar
// in your classpath.
//
// To run this example, you'll want:
// * commons-collections.jar
// * commons-pool.jar
// * commons-dbcp.jar
// * the classes for your (underlying) JDBC driver
// in your classpath.
//
// Invoke the class using two arguments:
// * the connect string for your underlying JDBC driver
// * the query you'd like to execute
// You'll also want to ensure your underlying JDBC driver
// is registered. You can use the "jdbc.drivers"
// property to do this.
//
// For example:
// java -Djdbc.drivers=oracle.jdbc.driver.OracleDriver \
// -classpath commons-collections.jar:commons-pool.jar:commons-dbcp.jar:oracle-jdbc.jar:. \
// ManualPoolingDriverExample
// "jdbc:oracle:thin:scott/tiger@myhost:1521:mysid"
// "SELECT * FROM DUAL"
//
public class ManualPoolingDriverExample {

public static void main(String[] args) {
//
// First we load the underlying JDBC driver.
// You need this if you don't use the jdbc.drivers
// system property.
//
System.out.println("Loading underlying JDBC driver.");
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
System.out.println("Done.");

//
// Then we set up and register the PoolingDriver.
// Normally this would be handled auto-magically by
// an external configuration, but in this example we'll
// do it manually.
//
System.out.println("Setting up driver.");
try {
setupDriver(args[0]);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("Done.");

//
// Now, we can use JDBC as we normally would.
// Using the connect string
// jdbc:apache:commons:dbcp:example
// The general form being:
// jdbc:apache:commons:dbcp:
//

Connection conn = null;
Statement stmt = null;
ResultSet rset = null;

try {
System.out.println("Creating connection.");
conn = DriverManager.getConnection("jdbc:apache:commons:dbcp:example");
System.out.println("Creating statement.");
stmt = conn.createStatement();
System.out.println("Executing statement.");
rset = stmt.executeQuery(args[1]);
System.out.println("Results:");
int numcols = rset.getMetaData().getColumnCount();
while(rset.next()) {
for(int i=1;i<=numcols;i++) {
System.out.print("\t" + rset.getString(i));
}
System.out.println("");
}
} catch(SQLException e) {
e.printStackTrace();
} finally {
try { rset.close(); } catch(Exception e) { }
try { stmt.close(); } catch(Exception e) { }
try { conn.close(); } catch(Exception e) { }
}

// Display some pool statistics
try {
printDriverStats();
} catch (Exception e) {
e.printStackTrace();
}

// closes the pool
try {
shutdownDriver();
} catch (Exception e) {
e.printStackTrace();
}
}

public static void setupDriver(String connectURI) throws Exception {
//
// First, we'll need a ObjectPool that serves as the
// actual pool of connections.
//
// We'll use a GenericObjectPool instance, although
// any ObjectPool implementation will suffice.
//
ObjectPool connectionPool = new GenericObjectPool(null);

//
// Next, we'll create a ConnectionFactory that the
// pool will use to create Connections.
// We'll use the DriverManagerConnectionFactory,
// using the connect string passed in the command line
// arguments.
//
ConnectionFactory connectionFactory = new DriverManagerConnectionFactory(connectURI,null);

//
// Now we'll create the PoolableConnectionFactory, which wraps
// the "real" Connections created by the ConnectionFactory with
// the classes that implement the pooling functionality.
//
PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,true);

//
// Finally, we create the PoolingDriver itself...
//
Class.forName("org.apache.commons.dbcp.PoolingDriver");
PoolingDriver driver = (PoolingDriver) DriverManager.getDriver("jdbc:apache:commons:dbcp:");

//
// ...and register our pool with it.
//
driver.registerPool("example",connectionPool);

//
// Now we can just use the connect string "jdbc:apache:commons:dbcp:example"
// to access our pool of Connections.
//
}

public static void printDriverStats() throws Exception {
PoolingDriver driver = (PoolingDriver) DriverManager.getDriver("jdbc:apache:commons:dbcp:");
ObjectPool connectionPool = driver.getConnectionPool("example");

System.out.println("NumActive: " + connectionPool.getNumActive());
System.out.println("NumIdle: " + connectionPool.getNumIdle());
}

public static void shutdownDriver() throws Exception {
PoolingDriver driver = (PoolingDriver) DriverManager.getDriver("jdbc:apache:commons:dbcp:");
driver.closePool("example");
}
}

Current Events with Phobos

2007-09-11T08:35:00.000-05:00

Recently my day job has been extremely busy and therefore I have not had much time to post or work on my favorite projects. I have been working on doing a test run of setting up a system from scratch, a Java application server with Phobos. My main problems have not been with Phobos, but with system details.

Setting up a Windows system was quite easy. Once the basic install was done, I installed Glassfish and deployed my shell Phobos application. No hitches there. I then set up a Centos 5 system and had some problems. Glassfish installed fine, but I could not get it to bind to the ports it needed. I disabled ipv6, the firewall etc, but still could not get it to go. I then tried Resin and had the same issue. When I tried running Jetty, it started up and ran just fine. After setting up a context in Jetty, I was able to deploy a Phobos app with no problem.

I also set up a new laptop for work. It came with Vista preloaded. Since I am looking to try using all open source products, I tried loading Centos 5, but it was missing the video driver for this particular laptop. I then tried loading Linux Mint, which is based on Ubuntu, using the live CD. It loaded up so I partitioned the hard drive using QT Parted, and installed Linux on half of the hard drive so that I have a dual boot system. I loaded Netbeans from the software repository, but could not get it to start until I also loaded the Java 6 JDK. I guess the JRE is installed by default. I also installed my favorite all around editor from jedit.org. I have been using that for almost eight years now.

I have been very happy with the Linux Mint distro so far. I hope to spend more time posting and working with Phobos in the next few months. I hope to see the beta of Netbeans 6 soon.

Connecting to MSSQL with in Phobos

2007-08-03T08:50:00.000-05:00

Here is an example of connecting to MSSQL server directly using jdbc
from inside Phobos.  This post shows how to make a connection only. You would 
use this for test purposes.  A production application would need a pooled
connection for performance.  That will be posted in the future.

*******************************************************************
// This will set up our writer.
// We could do this with a dynamic script or view as well
response.setStatus(200);
response.setContentType("text/html");
writer = response.getWriter();
// Set up our connection by specifying the driver
java.lang.Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
var user = "user";
var pass = "pass";
var strconn =
"jdbc:sqlserver://server:port;databaseName=database;selectMethod=cursor;"
var con = new java.sql.DriverManager.getConnection(strconn,user,pass);
writer.println("strconn");
if (con!=null) {
 writer.println("Connection Successful");
 }
// Close the connection.
con.close();
writer.flush();

Phobos vs Rails

2007-06-26T15:08:00.000-05:00

Summer time is very busy with outdoor activities, family vacations, and spending time enjoying the great outdoors. It is refreshing to step back and then come back to networks and computer systems with a little different perspective on problems and solutions.

I have been working on a test project with MSSQL and Phobos. I am using the MS JDBC driver, JPA and Phobos JPA generator. I have to compliment the Phobos team on the ease of use of the Phobos platform and focus on productivity of the developer. I see a lot of buzz about Ruby and Rails. When comparing Rails and Phobos so far, it seems that Phobos has just as much, if not more productivity with a greater simplicity.

An example of hooking up a page to a database would be to create your tables in your database, Create a project in Netbeans and run the JPA wizard, compile and build the JPA project. Add the JPA class to your Phobos project, and run the JPA generator Phobos provides. You now have a basic interface and all the infrastructure code for reading, updating, and deleting records. You can now focus on the presentation area of your web project instead of spending time writing infrastructure code.

While the Phobos team is still rounding out the platform, the simplicity and usability already really shines. With web developers using client side javascript, server side javascript is a natural choice for the server side as well.

Be sure to check out the JPA wizard on the Phobos web site at https://phobos.dev.java.net/tutorials/jpagenerator/index.html

Ease of Data Access

2007-05-29T21:51:00.000-05:00

Summer is here, and when you live as far north as I live, that means you get out and enjoy the great outdoors every chance you get. I devote much more time to learning new technology and programming during the winter months. That being said, I will be devoting some hours to learning Sun's web platform this summer. Phobos and Jmaki in particular. So far I have found Phobos and Jmaki very easy to work with. I find it extremely easy to use Java objects as well. I am looking forward to the final release of Netbeans 6.

There are a few issues that I think would help Phobos along. The first being that a simple data pipe is needed. Every user has data. Every simple website has data. In order for someone to find the whole platform easy to work with, there needs to be a simple data pipe. JPA is the new Java way of working with data. I agree that it is powerful and fast. However, there needs to be a simple pipe as well. Take the following scenario, someone has a database and they want to try Phobos out. If they had a simple data object that they could set a few properties, issue an sql statement, and get a data object back which they could then access to generate a presentation page, they would be successful getting there data and on to using Phobos to design an application. Now lets just say that they have trouble getting at their data, or something does not work right. Now they really have nothing to work with. They are now more likely to become frustrated and give up working with this new technology.

Now consider another scenario. The beginner user programs a simple data access page and now deploys it as a web app. However, because now it is running in the application environment, a data pool has to be configured to access your data. Now the beginner user is frustrated and stops using this new technology because they cannot figure out how to make the web app work on the application server. I know it is impossible to make a default pipe on every application server, but it would be help to have something be standard on at least one like Glassfish. There could always be a simple pipe out of the box, and then if you wanted more performance, you could complete the steps necessary to achieve that performance by using pools and/or JPA.

These all seem like minor issues to the average Java programmer, but for the beginner doing it for the first time, these can be huge issues. The JSF IDE builder in Netbeans is really RAD, but JSF programming is quite complex and far below scripting. The Phobos engine excels in simplicity, but a few added pieces of tooling would really make it fly. Data access just needs to work!

The devoted Visual Foxpro community on the Microsoft side was developed because of easy data access.

Phobos currently has a simple database library and also a JPA generator. These are pretty good, but I it still needs to be easier. The database library needs to be documented with some simple examples. The JPA generator is nice, but requires several steps. The Phobos team is doing a good job. I am sure better tooling is coming. Stay tuned!

Java One, Phobos, JavaFX

2007-05-11T22:01:00.000-05:00

I have been watching with interest what has been happening at Java One this year via the web. To be honest, I have never really paid attention to it at all except to see a random news story here or there. Since I have begun using Phobos and looking for ways to move business applications to the Java platform, I have been following Java much more closely. My main area of interest was to see what the Phobos team was presenting and how Phobos fits into the big Java picture. The next thing which jumped out and I found exciting was the JavaFX announcement. I saw F3/JavaFX several months ago, but really have not paid attention to it, but was pleasantly surprised by how far it has come and how it is being developed. It is exciting to see Sun putting effort into making simple, easy to use tools. In my book, this is finally an effort in the right direction to draw new, non-Java programmers into the Java platform. This is what needs to happen in order for Java to dominate and neutralize the operating system monopoly.

It was sad to see the reaction Java developers and Java bloggers being critical of Sun's efforts and JavaFX. With Phobos and JavaFX built on top of Java, Java is not going to go away. Java programmers will still be able to code in Java. What is the problem with building a simple declarative language with easy binding? What is wrong with designing an interpreted language running on the Java stack? What is wrong with bringing the level of complexity to write on top of the Java stack to a very simple proposition? It seems many Java programmers are their own enemy. It is time for Java developers to have some enthusiasm about the Java platform striving to encompass and invite, in whatever ways necessary, those developers who are using other languages. That does not mean forcing them to learn Java. That means creating a migration path that is feasible and comfortable, and giving them the tools to do so. Sun is finally doing it, and it is about time that Java developers and Java bloggers get in the game and support Sun's effort. It is in every Java developers best interest to do so.

Phobos And Data Access

2007-05-03T22:23:00.000-05:00

The last few weeks I have been working on some Phobos applications internal to our company and trying to work out the best way to access databases for both data display uses and form usage requiring persistence. The Phobos team has produced a generator which produces all the tiers of code which you can then modify once you have run the generator. The only stipulation is that you have run the JPA wizard on your database and have produced the needed JPA jar by using Netbeans. The JPA Jar is easily produced with the Netbeans wizard if you have a new database and there doesn't happen to be any wrinkles. I accomplished the whole task for a sample app in about thirty minutes. Considering I started with nothing and when I was done, I had a database with tables, a persistence unit, application server code, and a rough web interface, I would say that the process is pretty impressive! The Netbeans and Phobos team have a done a great job.

However, there is more to life than roses. It is not so easy when working with legacy data. For instance, it is not uncommon to have data in at least a couple of different databases. If we need to pull data from MSSQL and MySql into the same application we may have a problem. I ran into a problem running the Netbeans Entity class wizard to generate my JPA jar. Most of the tables could not be used because the primary keys were not recognized by the wizard. This isn't necessarily a problem, it just means if you want to use JPA, you have to hand code the classes in Java. If you are using Phobos and you run into this and you do not know Java, you might have to weigh just using jdbc as you can then script the object directly and you do not have to write Java code.

Check out the Phobos JPA generator tutorial at https://phobos.dev.java.net/tutorials/jpagenerator/index.html

On another note, be sure to check out Roberto's blog and his speech he gave at the Web 2.0 conference. the link is http://weblogs.java.net/blog/robc/archive/2007/04/phobos_at_the_w.html.
Roberto is one of the Sun engineers working on Phobos. He details the impressive speed and features of Phobos. The Phobos team has done a great job.

Phobos has the potential to really take off for the average developer if it can continue to integrate into the application stack. The way I view it, is that it sits very well under the presentation layer and works very well as the free flowing glue. The challenge will be, can it wrap the layers below it to make it really easy for the developer working in the Phobos layer. This what Ruby on Rails has done and its usage is skyrocketing. There are many more advantages to the Phobos/Java platform than the rails obviously, but ease of use and productivity are what will make a platform take off.

The Power of Phobos and The Platform

2007-04-20T21:36:00.000-05:00

I wanted to talk about the power and platform that Phobos offers and how easy it is to use. Let's take an example of wanting to accomplish a simple task like reaching out across the Net in a script and retrieving a web page and sending it back to the browser.

The first thing we have to do is figure out a way to reach out across the Net. If we were programming in say asp, we would need to use a com object or dll control as vbscript does not have the power to do that. Phobos does have a library function to accomplish this task, but lets assume that it didn't. What do we do? Hhhhmmmm . . . well every class in Java is available to us, or any Java class that is installed into your Phobos installation for that matter. So in order to solve our problem, I did a quick Google search for a Java example with the terms "Get URL Java" and landed on the following URL: http://www.devdaily.com/java/edu/pj/pj010011/index.shtml

Now this example will give us a step by step procedure for doing what we want to do in Java, but we are writing in Javascript. All we have to do is rewrite the example in Javascript. It is quite easy. Here is the code for a Phobos script to do the same thing:

********************************************************************
//Set status and content type
response.setStatus(200);
response.setContentType("text/html");
// Get writer
writer = response.getWriter();
// Create the URL object
var u = java.net.URL("http://192.168.0.76/");
// Open an input stream from the url.
var is = u.openStream(); // throws an IOException
// Convert the InputStream to a buffered DataInputStream. //
// Buffering the stream makes the reading faster; the //
// readLine() method of the DataInputStream makes the reading //
// easier.
var dis = java.io.DataInputStream(java.io.BufferedInputStream(is));
// Now just read each record of the input stream, and print it out.
while ((s = dis.readLine()) != null) {
writer.println(s);
}
//Close the InputStream
is.close();
// Flush to the browser
writer.flush();
*************************************************************************

See how easy that is! Using Java classes just like they are native to Javascript. Now, we should do some error trapping and other checking, but the code above illustrates how incredibly easy it is to use Java classes.

Another great benefit of using Phobos and Java for that matter is the Java Virtual Machine. It is so powerful, you sometimes forget what it is doing for you. For example, I developed a stub application on a 32 bit workstation and tested and ran it. I then deployed it to a 64 bit dual processor Windows server running the Sun Glassfish Application Server and of course it ran flawlessly. I also deployed to a Linux server running Glassfish and it ran the same. Portability and power available to every developer!

Phobos and the Java platform . . .

2007-04-16T22:16:00.000-05:00

Phobos has been getting more coverage lately and hopefully will continue to receive more in the near future. I believe Sun is on the right track to make a really good, lightweight, scripting stack for the average developer.

I think one of the biggest hindrances for Sun in years past was their lack of vision for reaching out to every business or developer. I think that has changed the last few years and they are on the right track on converting developers and businesses to their software. I have been a fan of Sun's for years even though I have used very little of their software. The biggest problem being ease of use and simplicity. Everyone knows that many, many huge enterprise applications run on Solaris and Java. However, for small business, it is a different ball game and it is hard to utilize all that power and stability. Java was originally written as a replacement for C. While Java was easier than C, a VB, VFP, Perl, or PHP developer wasn't really interested in learning C or Java. Yes, Java was more powerful, but the other languages were simple enough for the masses to crank out simple to somewhat complex applications. Java developers touted for years how great Java was, but you didn't see developers who were comfortable using higher level languages migrating down to Java.

This brings us to Java's opportunity which is now. Microsoft has discontinued VB6, VFP, and Access and is pushing their developers to migrate down to VB.NET or C#. Many developers would rather not do this. They are looking for alternatives. With tools like Phobos and Jmaki for the web, the landscape is looking better for those developers. I am looking forward to Netbeans 6 and the automatic databinding for the fat client, but I think the killer app would be to be able to use the Netbeans IDE tools for fat client, but be able to write your code in Javascript or a higher level language. When the masses can crank out simple applications to meet their needs, you will see migrations of developers who are looking to be able to develop cross platform apps.

I have seen some comments about Phobos from Java developers who feel we do not need another Java based web framework. I think Java developers should reach out to those who are not using Java and strive to encourage their movement to the Java platform. The Java community needs to show that it is reaching out to all developers. It has been a great stride for other languages to be ported to the Java platform.

Linux has achieved ease of use for the masses, but the lack of easy developer tools for the average developer to write applications to run on Linux has inhibited its growth. I think a Java foundation with high level languages can fulfill that role. Solaris is an outstanding operating system, but until it can be loaded on generic hardware as easy as Linux or Windows, it is difficult for people to use.

If you are currently using a Microsoft platform, you should give Phobos and the Java platform a try. Join the mailing lists and try writing a simple application. The Sun engineers answer questions and are a great help.

Next week I will discuss the similarities script developers on a Microsoft platform will find on the Phobos platform.

Phobos Ajax Site Layout

2007-04-09T22:41:00.000-05:00

Here is an example of a simple Ajax layout. This example will show how simple it is to do Ajax with Phobos and how little code it requires. Also, it should be noted, how clear the separation of logic and presentation is by following the Phobos architecture. In order to follow the logic, you should be familiar with the Phobos architecture of controllers and views. Let's get started.

We have a main controller which is commented below. Here is the code.

// Main controller for the application.
// define a controller module called "main"

library.common.define(controller, "main", function() {
// controller class (constructor)
this.Main=function() {
// insert instance initialization code here
// "show" action method
this.show = function() {
//Use the model global variable to pass information to the view.
model = {};
// render the /application/view/main.ejs view
library.view.render({view: "home.ejs",
layout: "main.ejs"});
}
//navigate function: routes and renders the view requested
//This method is used for Ajax call to update the center section of the layout.
this.navigate = function()
{
//Get the parameter for which view to render and send back
var strUrl = String(request.getParameter("url"));
//render the requested view back to the client
library.view.render({view:strUrl});
}
};
});

That's it! That is all the controller code we need for an Ajax layout.

Our layout is a two column layout with a header, but you can do the same thing with any layout. We have one core file which makes up the structure of our layout. This is main.ejs. This is our main view. Here is the code for it.

<html>
<head><link rel="stylesheet" href=<%= library.view.quoteUrl("/jmaki-standard.css") %> type="text/css"></link>

<title>Page Title</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript">
var req;
var isIE;
var list;
var entryField;

// This function will take care of the cal backs to the server
// You will notice that once it gets the data back, it sets the innerHtml for the main content
// section of the layout.
function initRequest(url) {
var list = document.getElementById("list");
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
} else if (window.ActiveXObject) {
isIE = true;
req = new ActiveXObject("Microsoft.XMLHTTP");
}

req.onreadystatechange = processRequest;
req.open("POST", url, true);
req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
req.send(null);

function processRequest () {
if (req.readyState == 4) {
if (req.status == 200) {
document.getElementById("maincontent").innerHTML = req.responseText;
}
}
}
}

//This function will be called by every hyperlink with a parameter of which view we want rendered.

//After it assembles the URL, it will call the Request function to get the view from the server.
function
submitData(strUrl) {
var url = <%= library.view.quoteUrl("/main/navigate") %> + "?url=" + strUrl;
initRequest(url);
}
</script>
</head>
<body>
<div class="outerBorder">
<div class="header">
<div class="banner">Application Name</div>
<div class="subheader">
<div>
<a
href="javascript:submitData('feedback.ejs')">Feedback</a> |
<a href="javascript:submitData('sitemap.ejs')">Site
Map</a> |
<a
href="javascript:submitData('home.ejs')">Home</a>
</div>
</div> 
</div> 
<div class="main">
<div class="leftSidebar">
Sidebar Content Here
</div> 
<div class="content" style="height:400px" id="maincontent">
<% library.view.layoutContent(); %>
</div> 
</div> 
</div> 
</body>
</html>

Notice how each of our hyperlinks call the submitData function with the name of the view they link to. They do not need a path to a file, just the view name. After the functions complete, The main content section will display the view without refreshing the page.

All that is left is the three files which the above links reference. Here they are.

The home.ejs file contains: <p>Hello! This is the home page</p>
The feedback.ejs contains: <p>Hello from the feedback page</p>;
The sitemap.ejs contains: <p>Hello from the sitemap page</p>

With this foundation, we can build any number of pages and load them without redisplaying the whole page. We might should add a few more things like a progress bar and a custom back button.

I hope to move to a web server and web pages soon so that the formatting for the code will be much more readable, but you get the basic idea.

Happy coding!

Phobos Appeal And Killer Apps

2007-04-05T21:03:00.000-05:00

I haven't had time to work with Phobos this week, but I am hoping to design an Ajax layout for a simple forum soon.
In my mind's wandering this week I was thinking about how Phobos could appeal to and be adopted on a large scale. A few things came to mind. It must appeal to the average scripter by providing easy data access to open source databases. It must be supported by web hosts as the average scripter is not using a dedicated server. It also must be marketed as a scripting platform that has ease of use as well as stability and speed.
At this point, I think if a developer takes the time to explore Phobos, they will see that it is a very conducive scripting platform. You can essentially plug in any scripting language and modify the platform to your needs. The database access is easy, but it does require the NetBeans IDE to avoid writing Java code.
Support by web hosts should be easy. Java web hosting is much more common than it was five years ago and is just as cheap as any other hosting. A web host could even market a solution as a javascript server platform. They could bundle in a few specific Java objects and deploy a basic Phobos web app. The customer could script their solution right inside Phobos without ever needing to deploy a web app or know what it is. This should also cure the reasoning of some that Java in a shared environment is not as stable as PHP. As long as Phobos doesn't hiccup, errors in code shouldn't matter.
The killer app for Phobos as a platform would be a Visual IDE. The JMaki project is really exciting from the fact that you can create your own components using simple text tools such as html, css and then of course javascript. This combined with the simplicity of Phobos is very powerful. The killer app would be if Netbeans had a visual layout screen similar to the NetBeans Visual WebPack or Visual Studio, but instead of custom controls written for an IDE, you could use Jmaki controls. Then the average web developer could create their own components for visual layout as well as script their pages.
After this was done the next killer app would be to be able to wrap Phobos up into a single window application with the embedded browser engine. Like the Gecko engine from FireFox. You would be able to write a desktop application with a scripting language using html widgets and of course it would be Internet enabled as it could make calls to servers or databases. You would also have a built in database engine for desktop apps using Derby. Now with one stack, you can write desktop apps, web apps, or Ajax apps with a scripting language, and these apps would be cross platform.
Phobos presents lots of possibilities.

Starting a New Project

2007-03-24T20:27:00.000-05:00

I am going to start a new project with Phobos so I can become familiar with how to write a web site and convert existing web sites to the Java platform. The first thing I did was read the Phobos overview located at the following URL https://phobos.dev.java.net/overview.html. If you come from a Java background the architecture is probably familiar to you. If you have been programming purely with html pages and script engines, the architecture may be a little confusing. It took me a few times through the documentation to get a few basic concepts.
So let's start with the first thing every web site needs and that is a layout. We will use the default jmaki layout for our sample app. If you start a new project in Netbeans and choose the default Phobos app you will be prompted to choose a layout. Choose any layout and click finish.
You will notice that I have an extra directory which was not created by the wizard called dynamic. Add this if you are planning to do this example. The Phobos team will be adding this soon. The dynamic folder along with the ejsp file extension is a new feature that is not in the documentation yet. It is a special folder which is accessed by the system whenever a file with the ejsp extension is requested. You can put any type of file in there and use it to script just like you would ASP or PHP. This is important to note as this is not the standard procedure for Java type applications.
Before we go into detail about the mechanics, lets follow a classic ASP example of how we would write a basic page with a layout. The default home page for the application is /script/index.js. Here is the code for it currently:

/* This script is called when the client tries to access the "/" URL.
* It simply redirects to a URL that causes the main application page
* to be displayed.
*/
// default index is to activate the main controller or page:
library.httpserver.sendRedirect(library.httpserver.makeUrl("default.ejsp"));

We are simply using the two library functions to redirect the browser to our home page. Because we used the ejsp extension, Phobos knew to look in the dynamic directory for the file. We did not have to give it a full path.
The code for our home page looks like this:

<% library.view.include("/application/dynamic/header.ejs"); %>

Hello from embedded Javascript running on a JDK

<% library.view.include("/application/dynamic/footer.ejs"); %>

The library.view.include function includes content from another file just like and include directive in ASP or PHP. So we included our header and footer and put our main content in between. We did have to provide the full path to the files because the extension is ejs. We could have just used the file name if our header and footer were located in the view directory. Phobos would have found them for us in that case.
When creating hyperlinks in our main content, we can link directly to file names in the dynamic folder and include our layout like we did above. This is typically how scripting has worked on the web and what scripters are used to.

Now we will look at how Java typically has done the same thing so we can understand the whole Phobos framework. You will notice in the directory layout that we have a controller folder and a view folder. In Java, you would use what they call a Model View Controller framework. If you are trying to visualize with the layout page in mind compared to the example above, what you need to understand is that we essentially link to the same controller ("file") with our hyperlinks and swap out the center content section of the page. This has its advantages as you will see as we progress, and it is still very flexible.

So with MVC we always have at least two files. We have the controller and the view. The model is the data shared between the two. In our controller we would put all of our script code and then paint the view. The view can have presentation code in it as well and adjust itself based on the data in the model. Here is the modified code for the index.js when we are going to use the controller:

/* This script is called when the client tries to access the "/" URL.
* It simply redirects to a URL that causes the main application page
* to be displayed.
*/
// default index is to activate the main controller or page:
library.httpserver.sendRedirect(library.httpserver.makeUrl("/main/show"));

Here we are sending a redirect, and Phobos knows where the controllers are so we do not have to give it the path. We are calling the show method of the controller.

Here is the code for the main controller:

/*
* Main controller for the application.
*
* This file was generated, please edit it as needed.
*/
// define a controller module called "main"
library.common.define(controller, "main", function() {
// controller class (constructor)
function Main() {
// insert instance initialization code here
}
// "show" action method
Main.prototype.show = function() {
/*
Use the model global variable to pass information to the view.
Alternatively, a view can access the controller instance by
using the expression:
invocation.controller
*/
model = {};
// render the /application/view/main.ejs view
//library.view.render("main.ejs");
library.view.render({view: "mainContent.ejs",
layout: "main.ejs"});
}
// export the controller class
this.Main = Main;
});

Consider this commented line:
//library.view.render("main.ejs");
This line would have rendered the view called main.ejs. However, we can have a layout file and a different file with the content for the main section. These commands will render both files:
library.view.render({view: "mainContent.ejs",
layout: "main.ejs"});
The mainContent.ejs is the center section of the page and the main.ejs is the layout.

The main views are just made up of html except that in the layout where the center content is placed, you place a function call with the following line:

<% library.view.layoutContent(); %>

I hope this has shown that Phobos can act like a traditional script engine and is flexible. I have attempted also to explain the semantics behind the MVC pattern which is a much powerful and maintainable when writing large applications.