I am close to release a new open source project that tries to fix many of the common problems in Fatwire and WCS development.
But before the release, I want to discuss those problems, since fixing them is the main motivations underlying my development effort.
Actually, many of the features of the framework I am doing cannot be understood unless you know which real world problems they try to solve.
This is not a rant. I also have a solution to those problems and it will follow in the next few weeks.
The biggest issue in Fatwire/WCS in my view is that you are stuck with JSP (or worse, with the obsolete, very limited and almost undocumented "Fatwire XML").
JSP are designed only to be a quick way of rendering a dynamic HTML page using Java code. Something that is 95% html and only a little bit of code. They are no way meant in no way to be a complete tool for doing generic Java coding.
They provide the flexibility of immediate availability (since they are recompiled and reloaded on the fly), and they provide the "markup first" approach that is useful when you need to render a lot of HTML and only a small part need to be coded and rendered dynamically.
Indeed this JSP flexibility comes with a lot of limitation, while the coding in Fatwire development tend to be pretty complex, so complex that you end up writing big JSP so full of code that may you have difficulties finding the HTML.
Here some of the limitations of JSP. First and before all, because a JSP is a single method of a single class, you generally are not supposed to define methods and classes. You actually can define classes and methods, using the "<%!" syntax.
Hovewer, since it is not the way JSP are supposed to be used, you cannot reuse any defined method in another JSP . This is even worse when you also define a class. You can create classes inside a JSP but you cannot reuse that class in another JSP.
The only way of having code shared between different JSP is to create a separate jar with all the code and deploy in the application server Coding such a jar is relatively awkward, because you have to build it, deploy and restart the application server for every change. So usually this is done rarely.
For this reason, building libraries of code is not normally done in Java (as it should). Instead, the common practice is to create a library of "elements" called by JSP.
The problem is that a CSElement is not really meant to be a library doing complex things, it is meant as a medium to generate repeatable rendering of common elements.
The semantics of calling CSElements, and using them as a library is, frankly, disgusting. There is no way return value from a CSElement , so you normally use a global environment and side effects (altering the value of a variable value in a shared environment).
The JSP "language" does not offer any enforcement to using a CSElement as a library call, so everything is left to convention. You need to document clearly which variables are changed to see what is returned. This practice is error prone, hard to read and even harder to maintain.
Also it happen often that a CSElement "pollutes" the calling enviroment, so you need to use pushvar and popvar to preserve the environment. And this makes the whole procedure even more disgusting, unreadable and produces really bad code, where a lot of complexity is there just to move around variables, protect them and read side effects.
Last but not least, the invoking CSElements is really verbose and typing an invocation method is often so long that you copy and paste code. Long code doing little is also very hard to read.
1. What really is needed is a way to code in full, plain, clean Java, not in JSP. Classes offers all the power needed to build complex programs, and a JSP are a simplified AND limited form of Java classes. Using Java will immediately give you the ability to write methods and classes, keeping them totally reusable.
2. However you need to retain the ability of seeing immediately the result of a change because restarting the application server at each change is usually not really practical: it is so slow that developers to avoid it will prefer to push tons of code in the JSP. A solution could be "JRebel" but since it is expensive for some teams (most notably indian teams) buying it can be a problem. So that solution should be cheap.
3. Coding in Java you will also want to avoid ton of out.println("...") filled of "\" to escape quotes just to generate HTML. Probably you may not not the "HTML first" approach of JSP and you may prefer the "code first" of Java, but you still want an easy way of generating HTML.
4. Last but not least, JSP offers some well defined tag libraries for rendering the content model. Since the equivalent Fatwire Java API (the Asset API) is not even close to the quality of tag libraries, you need some efficient way of invoking tag directly from Java code.
Actually we have just started, a lot more will come. So please wait, there are more problems to discuss in the next posts. And the solution will follow, it is a promise. So stay tuned.
