Application Development Meanderings

I was looking through XAML again. I like it. While not perfect, I like the underlying presentation framework (WPF) that XAML maps into. XAML itself is not particularly interesting. The presentation framework is, however. In eclipse RCP, the presentation framework also exists but seems to get aborted at the view part level. The workbench part, the view part, etc. all define a logical UI hierarchy with resources (although fairly specific to the RCP). At the view part level, however, the hierarchy starts breaking down. That's where the managed form classes come in. In essence, this logical hierarchy "renders" the UI using createPartControl() using SWT underneath. Personally, I think the presentation framework has alot of good ideas and is generally well constructed. I wish something as flexible as this was used ontop of SWT to build the RCP framework. In a sense, SWT has some of the presentation framework with a logical set of SWT widgets, etc., so its not an alien concep...

One issue I have constantly had trouble with is setting the directory of HBM files in a separate plugin than the main plugin in an eclipse+hibernate+spring RCP application. No path specification work except something like the following: <property name="mappingDirectoryLocations"> <list> <value>classpath*:/**/org/top/dirwithmappings</value> </list> </property> The standard examples in the spring and hibernate reference documents never worked for me. This classpath works even when the HBM and POJO files are in a different eclipse plugin. I believe that the hibernate references do not account for an OSGI environment although the syntax obviously helps across different jars.

I've had alot of challenges getting hibernate tools to generate my pojos in 2 separate processing steps. Some teams may generate the POJOS directly with annotations using hibernate tools but I have found that to allow me to make modifications to the POJOs and control various aspects of pojo generation that is not currently supported by the tools or requires changing the template (which is not hard to do) is difficult. For example, if you generate a pojo directly from the JDBC configuration, then you cannot specify an "extends" class unless you change the template. I have found that generating the pojo through a two-step process gives me the control I need without resorting to changing the template. Here is the process I used. Step 1: Create a reveng.xml file for the application. Use this reveng.xml file for Step 2. Step 2: Create HBM files using a dedicated hibernate console and a dedicated code generation configuration. Use the reveng.xml file from Step 1. Step 3: Modif...