Radicore for JAVA

An experienced Java programmer came across my work, and what he saw intrigued him enough to see what an implementation in that language would be like. He took my designs and created a prototype, and the results impressed him so much that he contacted me about taking his implementation further. Here is an extract from our correspondence:

I am rather surprised that a Java developer would take my design seriously as I was under the impression that the Java world was full of superior programmers with superior designs and a ready collection of superior frameworks (such as Struts).

Well, you are right about the fact that there are tons of frameworks and design patterns to choose from in the Java world and the OO world. This is particularly true on the server side where there has always been a lot of frameworks that were supposed to "save the day". I was once working for a company with CORBA solutions that was supposed to be the solution for all server side applications. This was not true of course, CORBA is good for EAI but not for building web applications.

Then came J2EE which I was convinced being the greatest thing ever to happen. But I was proven wrong there while working on a J2EE project in the wireless sector. This project was later taken over by a US company. I followed the project to the US and worked with some clever guys that told me that J2EE was just slowing things down and was more of a marketing ploy than something actually useful. So we removed all our EJBs and ended up with a server that could run in Apache Tomcat, without losing any features, it was more like we gained speed and independence from costly J2EE servers. Don't get me wrong, J2EE servers usually have some good things like stable web container, proven multi-threading, connection pooling etc. But it's nothing you can't get from Apache.

So what's next? Web Services. This is the next thing they try to pack onto us as the life saver on the server side, but it's just a communication protocol based on XML and HTTP (good for EAI).

The thing that I have discovered that most people do wrong is that they start on the server side when designing a new product, not realizing that if they finish the server side, so they can fetch some business data through business objects, they still have to design the whole UI framework (Menu system, RBAC, forms, security, navigation, paging etc). And the UI is the biggest part of the system, probably 70-80% of the job. It's very easy in J2EE, CORBA or with Web services to design and implement a person object, for example, which you can do CRUD on. However, most server side CRUD patterns do not take into the account that you want to do paging in the UI, so it comes as a nice surprise later on (you are f****d up basically). I'm generalizing a little bit but I think you get the idea!

So J2EE, CORBA, Web services etc can't help you there. So there are UI frameworks that are supposed to help you solve this. These are java frameworks like Apache Struts (that you mentioned), Apache Cocoon, Apache Tapestry etc and in other languages Ruby on Rails, Magic e-Developer, Oracle Forms.

These frameworks make a good job in separating Presentation, Business Logic, and Data. However, they do not come with a menu system, RBAC system, audit logging system, access logging, login system, navigation system, paging and scrolling etc. This might not be that much of a job to create in the beginning (if you have a couple of months to spare) but the big problem is that you have to create every form from scratch. None of these frameworks have form templates. You basically have to do all that from scratch. We were using Struts with JSP in the US wireless project and every time you had to do a new CRUD implementation you would have to do Form, Action and JSP for every page including unit tests.

Another thing you have to think of when designing your UI framework from scratch is that it should be customizable by your customers. And that's often forgotten in the beginning.

Unit tests I think are one of the biggest advantages of Java programming when you can write a JUnit test for everything you do and then get regression testing before every check-in. However, with a UI framework that requires you to write every CRUD form family from scratch it's cumbersome and error prone to do almost the same unit tests over and over again (often when time is short you "forget" to write you tests). It's much better if you can have a generic framework like yours with build in unit tests, so you do not have to write tests for every single form you create. It's better to have tests for LIST1, LIST2, UPDATE1 etc...

What makes my design stand out from all the others?

The foremost thing that makes your framework incredibly fast is the form template families. I will just take an example from last week when I created the following forms for your RBAC system Application Function (what you call task), Localized Texts for Application Function, Form/Dialog Type, Module/Subsystem. That's 4 x 6 = 24 forms that I implemented in less than 10 hours including everything. And then I got the menu system, navigation, paging, scrolling, messaging, etc for free. If I would have to do this now with Struts I don't even want to start thinking about how much time it would take, probably 3-4 weeks (NOT including menu, security, paging etc).

I am especially intrigued as I have already been heavily criticised is various PHP forums for doing things that "real" OO programmers would never do.

I think a lot of people might look at your framework quickly and make up their mind without really understanding it. It takes a while to get into to it (I have worked with and read about your stuff now for more than a year). But if you take the time to understand how to use this framework it really is fast and easy. So maybe a RADICORE quick start guide could come in handy! Also, a lot of people don't want to be told that they are using some slow inefficient method of developing their web applications. After all they spend all this time learning Java and Struts and now somebody comes along with a framework that's super fast and efficient, that can't be for real, I must find some bad things with it, it's not even written in Java...and not "proper" OO!

But time is money, and whoever does not adapt to the latest and best technology will be left behind. I definitely think your framework is the future for developing administrative web applications.

I myself used to be a "must try new Java technology/feature/framework freak" for the sake of it just being there, not looking at if it's will benefit my customers. You can't just choose J2EE or Web services because it's hip and cool. You have to look at technology that makes it possible to develop a web application in the shortest amount of time according to the customers requirements.

As the Java world is supposed to be full of "real" OO programmers who do everything "according to the recognized rules" I am surprised that a Java programmer would take my work seriously.

They should get to know the framework better, maybe through my Java implementation we can convince them to do just that.

How does my design actually perform against existing Java frameworks?

It's not comparable as there are no other frameworks with a Menu system, Form template families, RBAC, audit logging etc. It's much, much faster than anything else.

Is it easier to develop?

Yeah, it's a no brainier to create an administrative web application with this framework. However, I have not tried to implement graphs and reports yet. But if the framework contained solutions for that also it would be a killer...

Does it run faster?

I have implemented it in Java 5 and the latest TrAX (Transformation API for XML). This API gives you the possibility to create Translets (compiled stylesheets) that run very fast after you accessed the page for the first time (I cache the Translets). You can even compile every stylesheet before and ship with the application package but then it would be more difficult to customize it.

I think this solves the problem they had in the Java and XML world that XSLT transformations are too slow to really use in a production application. It's not true anymore. To sum it up, it's very, very fast, no problem whatsoever.

What is so different about my framework?

The form template families are the main difference. They are really the key to this whole framework from my point of view. Without them you would still have to create everything from scratch when starting with a new CRUD.

If it is as good as you claim then it would go some way in silencing my critics who claim that my designs are rubbish and would never be implemented by "real" programmers in a "proper" language.

It is so good that I would like to create and market a full implementation in Java so that if someone is about to start developing an administrative web application then they can have a choice of languages, PHP or Java.

We initially had plans for him to become part of Radicore Software Limited so that we could market the two implementations under the same name. It was planned to create identical applications which used the same screens (because of the common XSL stylesheets) and the same database schemas so that it would be impossible to tell (apart from looking at the URLs) if it was the PHP or Java version that was being run. It was thought that by using my existing designs and existing documentation that it would save a great deal of effort. Unfortunately those plans fell through at the last minute and he decided to make his implementation available under a different name.

If you want to check out the Java implementation of the RADICORE framework then take a look at http://sourceforge.net/projects/webfastforms/.