Chris Johnston

For my open source Java app, I have decided to go with “Wicket.”:http://wicket.sourceforge.net/ My decision really comes down to two things; 1) I like the idea behind Wicket, I like the website, and I like that it is suppose to be fun to program with and 2) I have to learn something so why shouldn’t it be Wicket. And getting a comment from one of the developer’s didn’t hurt either.

Plus, with working at ThoughtWorks, I figure I will have plenty of time to learn other frameworks, so why not learn one of the up and coming ones. At least this way, if I am ever put on a project at the beginning, I can argue for or against its use intelligently.

Thanks to all the people who offered their suggestions. So now I just have to get my butt in gear and start coding.

This evening I was working on TeamDocs and had to make the decision about where to put some validation code. The code in particular is a bit of logic that I use to determine if a directory name is legal or not. In the code, I have a Directory and a DirectoryManager. The DirectoryManager is used to create new Directory objects. In terms of workflow, the new directory name first is sent to the DirectoryManager where it is used to create a new Directory. So, should the validation logic go into the setDirectoryName method in the Directory object or into the createNewDirectory method in the DirectoryManager?

Personally, I can see an argument for both. On one hand, the Directory object should posses the knowledge of what makes a valid directory name. On the other hand, by placing the logic outside of the Directory object, it allows that logic to be more dynamic. I can check if a name is legal based on the OS or some user configuration. In addition, I am not sure if Hibernate allows setter methods to throw exceptions. I will have to look into that.

I think the argument for putting the validation logic into the Directory object is more persuasive given the current trend away from “Anemic Objects”:http://www.martinfowler.com/bliki/AnemicDomainModel.html.

In the midst of changing hosting companies and domain providers, one thing that I forgot about was the TeamDocs website. This has now been recreated and updated. Instead of using Drupal, I am using, instead, MediaWiki. This is more of an experiment to see how a Wiki works for software projects.

I have also officially moved the code from Javaforge to Google Code. Google just makes things so easy, like allowing anonymous downloads of the source code. I still haven’t figured out how to do this on Javaforge.

Well, the filter/interceptor solution that I found for solving the “lazy loading problem in TeamDocs”:http://www.fuzzylizard.com/archives/2006/07/29/753/ didn’t work, so I had to remove all lazy loading from the app. This took a little bit of work to get all the lazy="false" statements put in the right spots. However, it now works. This is probably not the best solution, but it is good enough for now. Once I pick a web framework I will have to revisit this.

On the other hand, The entire object graph is connected so I am not sure what the best solution is. It may simply be to load all the objects on startup and cache them in memory somewhere. Then when objects are needed, they are simply retrieved from the cache and only persisted via Hibernate when they change or objects are added. I am not sure.

As for my stupid mistake, I was trying to create directories on the file system and nothing was working. I kept getting a false result when calling dir.mkdir(). Moral of this story, always make sure you call the mkdirs() to ensure that all parent directories are created as well. I gotta read the Javadocs more often instead of just picking the first method and going with it.

As far as TeamDocs is concerned, I can once again log in, see the explorer view (the view that shows a level of directories and documents) and create a new directory. Cool, now on to uploading documents.

BTW, for anyone for whom the previous paragraphs did not make sense, TeamDocs is a document management application that I am creating. More information can be found at the “project website”:http://teamdocs.fuzzylizard.com, which is woefully un-updated and slightly out of date.

To try out “Google’s new code hosting”:http://code.google.com/hosting/, I uploaded all the “TeamDocs source code”:http://code.google.com/p/teamdocs/. Using SVN on the command line and the import statement, it took about 2 hours. And I lost all of my history. I still have all the code checked into my “JavaForge account”:http://www.javaforge.com/proj/summary.do?proj_id=331 and I may continue with it for no other reason that I can retain all the history. However, for new accounts, Google’s solution should work fine.

I am seriously thinking of moving “Teamdocs”:http://teamdocs.fuzzylizard.com to “Google Code”:http://code.google.com/hosting. The main reason is not out of any dislike for its current home on JavaForge, but because I really like the simplicity of Google. One thing I have really not liked about JavaForge is that it is simply too complicated. There are too many options and too many tabs and too many things to administer. Google code hosting is simple and easy to use. When or if I make the move I will post the details on the teamdocs website.

“ZDNet has an article”:http://blogs.zdnet.com/Burnette/?p=151 up on Google Code along with a series of photos.