Wednesday, April 30, 2008

JavaScript On The Wire

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.

Friday, April 11, 2008

Phobos Most Important Feature - It Stacks Up

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.