I am working to use reflection to generate a POJO from data models defined in Jython – DB4O can only persist Java ojects. However, as I sort that out and  prepare for my next DB4O/Jython/Django post, let me share this good advice for any developer who builds any sort of web application in any language.

These seven habits for developing secure applications target PHP developers, but they constitute good advice for you, even if you are working in another language. Take heed.

Also, some of you will be think about Jython performance. Performance is not everything, but if that is what you care about, then Dhananjay Nene has written this excellent article to help you understand where Jython stands compared to other languages and implementations, including Ruby. (Be sure to note that Python produces the fewest lines of code.)

I also plan to play with Django 1.0 because it is cool. But, I also plan to spend some time with the Zend Framework – I believe that it is the best choice for a church web site I am working for Faith Fellowship Christian Assembly. (Is that too much? Yes, but any time spent learning is not wasted.)

Why The Zend Framework?

The Faith Fellowship site is hosted by dreamhost, which provides good PHP support. My goal is to put Faith Fellowship in a place where anybody can easily support the site. PHP programmers are easier to come by than Python programmers who can work with Django.

So in short, the reasons are:

• PHP has a large community – programmers are easy to find.
• PHP is well supported by hosting services.
• The Zend Framework has a rich set of components.
• The Zend Framework employs the MVC approach.
• The Zend Framework does not force you to use the whole thing – just use the parts you like.
• You can use Smarty templates if you prefer. (Very good docs.)
• The documentation and the examples are fantastic.
• Zend isn’t going to go away any time soon.
• Zend is distributed under the new BSD license – play with the code if you like.

Does this mean I prefer the Zend Framework to others? No, it does not. But, given my hosting arrangements and all of the other considerations, I think this is the best Open Source solution for this particular client. I prefer coding in Python. If the Ruby on Rails community continues to grow, and the documentation improves, and the market is swimming in RoR programmers, I could choose RoR. (Please note: There are some fantastic RoR books, but they cost money. The free docs are not as good.)

I might also recommend Django if my client’s hosting service supported it well. The Django docs are great.

Time to go for a bike ride in the fall leaves.

I have developed an interest in getting DB4O to work with scripting languages, as regular readers of this blog will know. I have had less time this week than I would like, but I will be posting some examples of DB4O working with Jython.

 I have been thinking of building a small web-enabled repository using Jetty or Restlets with Jython and DB4O. Sorry if this does not happen instantly, but it will happen.

I also want to return to Ruby on Rails running on JRuby – I would like to look at integrating DB4O support with Active Resources. It would be nice to define a model and get DB4O CRUD at no additional cost – this seems like a worthwile effort, and it would be good to get experience with Active Resource.

Then, after tackling RoR and Jython, I would like to try my hand at using DB4O from Quercus. Quercus is an implementation of PHP that runs on the JVM, giving PHP the ability to use Java libraries like DB4O.

Later, I would also like to try to use DB4O from Grails, another Ruby on Rails derivative that runs on the JVM using Groovy. The possibilities for DB4O are huge – DB4O can go wherever the JVM can go.

It looks like Microsoft’s common language runtime approach is taking the Java world by storm – the JVM is becoming the new CLR. For a long while now, it has been possible to author applications in multiple languages and run them under .NET or Mono. I think that is a good idea. Java is on the right track – it has to become easier to write applications that run on the JVM.

Obviously, DB4O is available in any language that runs on the CLR. However, I just want to make note of the trend of running scripting languages on the JVM – this opens the doors for DB4O in many important ways.

When I has some solid code, and a tutorial to go with it, I will begin posting in the DB4O forums.

I will provide details later – I will probably also post to the DB4O forums – but here is the readers digest version: I have found that Jython and DB4O can play well together.

It was easy enough to create an instance of any Java class, use it, and save it using DB4O. However, I was unable to save my own objects, even if I inherited from another Java class. There is a way to compile these classes such that they can be used in a Java project, but that seemed like an extra step to me – I wanted simplicity.

To keep things simple, I created my basic classes using Java, and then I created a jar of the class files. I was able to create instances of these using Jython, I was able to use them, and I was able to save them. That seems good enough for now. I had hoped to find a way for someone who had little or no knowledge of Java to create classes and save them, but I still think my approach is useful.

If one is prototyping a new application, Jython is good if you want to write less code, and if you want to quickly develop your ideas. I will demonstrate this by recreating examples from the DB4O tutorials. Jython is a good glue, and I hope to show how it can be useful.

I expect that my approach will work with JRuby as well, which means that DB4O could be made available in Ruby on Rails running on the JVM. There is probably a good way to create something that looks and acts like Active Record for objects that works with DB4O. Active Record shows that you do not have to use SQL if you do not want to – the next step is to show that you do not have to use an RDBMS is you do not have to.

Watch for code and examples when I have time.

In my previous post, I mentioned in passing that I like Python better than I like Ruby; therefore, I am more attracted to Turbogears than Ruby on Rails. That statement is true. I also stated that I could change my mind as I got used to Ruby on Rails.

One of the features or characteristics of Rails that could make the difference to me is number of plugins that are available for Ruby on Rails. The community has been very active. I have just started using the streamlined plugin – I will let you know how it goes.

Update: streamlined seems a little temperamental. I am sure I am the source of the errors, but my expectation is that frameworks should just work. I am displeased. I am getting the following error:

rake aborted!
undefined method `Join’ for File:Class

I can roll my own code in the time it would take me to figure this out. Rails may have an advantage because it provides many plugins, but they have to be very easy to use. And, there has to be some quality control. Perhaps a rating system by people who are currently using each plugin – perhaps there is one out there. Oh well – I will continue using a plain old scaffold for now.

I want to return to my DB4O/scripting languages experiments, but getting the kids back in school has eaten into my time. However, I have been playing with Ruby on Rails.

I have this to say about my choice of RoR for a small personal project:

1. I feel compelled to learn how to use this framework because it is popular
2. Many of the jobs I see posted these days mention Ruby on Rails; therefore, I want to have bragging rights.
3. There is a growing number of books about this framework, which makes it a good choice if I want to find someone to maintain my code later.
4. The Ruby on Rails community is very active – there are many available articles, tools, plugins and extensions.
5. Clients like new technologies, but not too new: RoR is a good choice. It is new enough to be cool, and established enough to have credibility.
6. An old fart like me has to show that he is keeping up – learning new things is important.

Having said all of the above, I prefer Python to Ruby. It is a matter of taste, but Python is cleaner and easier for me to write. There is something about the culture of Python that I am more comfortable with. Therefore, I am more attracted to Turbogears. However, I think it will be worthwhile to earn the right to my opinion by learning how to use RoR first. Then I will be able to comment with some authority.

On the other hand, I could change my mind, but I doubt it. However, I am sold on the basic approach that is taken by RoR. I just do not feel that the approach depends on Ruby to work well. For a humorous look at RoR, see this video that contrasts Ruby on Rails with traditional PHP.

Upon investigation, I found that JRuby throws a wrapper around Java objects in some circumstances. The wrapped object cannot be saved by DB4O, or so I have concluded. My follow up strategy was going to be to define a class in java and try to instantiate it in JRuby to see if it would save to a file. I may be on the right track.

A search of the Db4O forums has led me to the following excellent information, provided by Jason Thomas. I will attempt to make use of this information, and I will write about the result. While you wait, follow the link I have posted above – it is interesting.

Note: (Added November 20, 2008) I have since returned to my investigations of how to use DB4O using scripting languages running on the JVM. See my work with Jython and the Django framework using DB4O. My BS theory of JRuby throwing a wrapper around Java objects is probably out to lunch. I may come back to this, but feel free to see what I am doing with Jython to see if it applies to JRuby.

I have managed to get JRuby up and running, and I am using Netbeans to edit my code. I am pleased. I can create Ruby on Rails projects, and I can start and stop servers from the IDE. All good.

Today, I started to play with DB4O – I have hit a small snag. The objects I want to save will NOT save – I am getting an ObjectNotStorableException. I am sure that all I need to do is read some more – my objects are Ruby objects not Java objects. (I thought I was inheriting from proper Java classes, but I am sure I can work through this.)

I will also try this with Jython – and, I found a version of PHP5 that runs on the JVM. I will keep you posted. As usual, I do not have a lot of time.

Today, my six year old step daughter and I rode our bikes to the bakery to get breakfast for the family. This was her first purposeful bike ride, and it was the first time she had every ridden on the road. She was very proud of herself – and I was proud of her, too.

In the afternoon, I proposed that we are drive out to Carleton Place for no reason. We looked around, bought some books, and had supper at a lovely little Irish pub. Technology had to wait, and that is as it should be.

However, I would like to find time to generate some excitement about DB4O for scripting languages that run on the JVM.

DB4O is not a database, per se, or a database substitute. It is an object persistence tool – or, an object database. An object is more than data. As such, it can help you save, delete, find and update objects that have been created using either Java or a .NET based language. On the .NET side, therefore, it is possible to use DB4O with IronPython or IronRuby – pretty well any language that runs on the CLR. I have not done this myself, and I have to point out that code examples may be in short supply, but it can be done.

Some people might assume that Db4O is more versatile when used under Mone or the .NET framework, but that is not so. The Java community is busy finding ways to make dynamic languages run on under the JVM. Notably, there is Jython, an implementation of Python. There is also JRuby, an implementation of Ruby. I have even read that Ruby on Rails will run under JRuby, which would give RoR developers access to all sort of Java class libraries.

Can you imagine RoR and having access to objects that are being managed by DB4O? In the DB4O forums, the odd person will ask if Db4O will work with PHP, or some other language. The answer should not always be no. I do not have the time right now, but if someone is playing around with these ideas, I would like to here about.

Somebody will get Django to run using IronPython – perhaps even Turbogears. Combining these frameworks with the CLR or the JVM could make it possible to use many other computer languages with DB4O. The door is not closed, but someone needs to make it happen. This is an interesting area. I am interested in using JRuby to run on the JVM, opening the possibility of using DB4O with Ruby on Rails – then, it would be interesting to build a version of Activerecord using DB4O. (Justing thinking out loud.)

Hint: If you use Jython, the key is to inherit from a Java class. If you create an object based on a Python class, it will not persist using DB4O. Good luck.