My hope was that it would produce pages with the latest ajax-friendly table sorting headers -- sadly it didn't. In addition, this version retains the practice of generating pages that use labels and column headers wired to a particular language (English) rather than allowing the headers to be language dependent messages, even though the pages fully support localization (via language specific message_x.properties files in the resources directory).
I was in the process of fixing these issues manually via emacs using these instructions (I find that emacs makes it easier to select the files that I want to edit -- Netbeans picks up too many files and deselecting 70 or so "extra" files is too much work). While making these changes, I was discussing a new system with one of my clients and recommended that they consider an open source solution since they could change it (or hire somebody to change it) if at some point they encountered something that they didn't like. I thought this better than the alternative of waiting for a potentially unresponsive vendor to pay attention to their problem.
As was saying this, I thought to myself: "Seam is open source, maybe I should try to fix the code rather than edit the result." I'm usually hesitant to go down this path. Sometimes it works, but my a priori estimate is that the process of understanding the code structure, getting the build environment running etc. costs a day (or more) before anything productive comes out the other end.
However, as a proof of principle, I thought I should give it a try and see how it went.
I'm very happy to report that given a combination of good architecture and good tool selection on the part of the Seam team, making these modifications was almost trivial.
Let me explain why, and encourage you to "do this at home."
The core reason is that the seam generate-entities command operates in a number of phases, one of which generates the .xml and .xhtml files using freemarker template files (
.ftl). This allows the required changes to be made without either looking at the java involved or developing any understanding of the calling structure, etc.
./seam-gen/view/) are pretty much self-documenting (which is handy, given the level of documentation included in the files) and very easy to change -- errors thrown by the freemarker engine are clear and easy to work with.
A couple of (minor) caveats
.javafiles in the
src/actionwill need to be removed between runs of
- I think it is a good idea to point the seam generator at a different target directory (specified by
workspace.home") while debugging so that you don't accidentally overwrite edits that you've already made (oddly I thought of this BEFORE I ran the generator)
In summary, if you find yourself making a lot of changes to seam generated files, change the .ftl files instead; it can be much, much easier.