Application Development Meanderings

Based on my previous post, I have been looking into AOP as a way to help with long conversations. The thinking is that I want to create DAOs and other data access objects but not specifically break spring and hibernaet provided methods. Spring itself uses a proxy object on the session factory so that when you create a new session, spring

Based on my previous post, I have been looking into AOP as a way to help with long conversations. The thinking is that I want to create DAOs and other data access objects but not specifically break spring and hibernate provided methods. Spring itself uses a proxy object on the session factory so that when you create a new session, spring "catches" the call for a new session using the proxy, then manages the session for you. In a similar way, you really need to make the use of long conversations (an extendend persistent context) more optional and transparent to data access objects. AOP is a good way to do this. Also, after much consideration, I do believe that in a RCP setting, long conversations are highly application specific but I think they do share characterstics that are very different than web applications. Web applications have better mechanisms for indicating a start and stop approach (a transaction for example). In a RCP, depending on the application, it may be diffi

After much thought it appears that easily grafting long conversation support into standard spring is challenging. It forces code into the DAOs that should be made more transparent--perhaps through AOP etc--but is a twisting of how some of the core classes in spring work around hibernate (which is based more or less on session-per-request). The way I see it, the two key classes are SessionFactoryUtils and SynchronizationTransactionManager. The STM class is merely a way to stash global variables on the thread. They can be keyed (because the data is stored in a hashmap inside of the STM class) so it is a general purpose mechanism. STM also has TransactionSynchronization support which are really just listener objects listening to transaction events such as begin, commit, etc--its a transaction specific listener/observer pattern. The real crux is probably in the SessionFactoryUtils class. This class supports getting the current session from the STM based on the session factory. In the case

As I go through and implement my DAOs, I noticed that the generic DAO defined by the hibernate site and in books is a good design and has features that I like. However, Spring recommends the use of HibernateTemplate to get uniform exceptions thrown regardless of the underlying data access mechanism. I like that as well. The problem is that when combined with my long conversations (see a previous blog), it all gets quite messy. However, one option that allows me to write non-HibernateTemplate based DAOs is where you can annotate the DAO with a @Repository attribute then place the following definition in your application contexts where the DAO is defined: <bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/> If you have a hierarchical set of app contexts, the above bean definition must be placed in each bean definition. The only issue is whether the DAO needs to keep the session state or not. If so, the the DAOs cannot be used acr

The more I look into the property support in WPF the more I think was correct in calling out that it is nothing more than a type-safe way of having extensible properties for beans. This is like the DynaBean in apache commons beanutils for non-class defined properties (but borrowing from others) and standard bean properties. Since you want change notification and other features in your properties, the DependencyProperty mechansims help you define properties that have nice bean setters/getters in your class while attached properties help you define a property in any class, and use it a class that implements DependencyProperty . Let's see how to do this differently. Suppose you define the interface: public class DependencyObject { public Properties getProperties() { return ... } public void setValue(String key, Object value) { getProperties().setProperty(key, value); } public Object getValue(String key) { return getProperties().getProp

I was looking at WPF's property system ( here ) and notice that one item that is going on is that the property system is really designed to allow a multitude of objects to expose properties for XAML usage. That's a good thing. The other component (with attached properties) was to allow the ability of other objects to share values between different, unrelated objects. These objects may exist in a hierarchy or not. In this way, the property could be thought of as a shared value and that is what a ValueModel (from jgoodies and smalltalk) do. An attached property also allows unrelated objects in a hierarchy to declare properties that the higher-up object wants the lower object to define. Then the higher-up object can access the lower-object's specific values. This is sort of like extending an unrelated class with a property that is defined in another class but doing this quite manually. This last use case could be implemented by ValueModel's. The parent object could have a

My application has all of the resource stored in a database. It is entirely database driven. I want to provide a navigatable view of the these resources in my RCP. Using the common navigator framework (CNF) I can provide a view to navigate these resources rather generically. However, the classic problem is that while the toplevel objects in the CNF are defined logically in the application many of the lower level resources (in the tree view) are going to be from the database. For example, the top level resources have contacts and security objects. I represent these directly in code similar to IResources in the eclipse world. However, the list of contacts come from the database directly and are represent as domain objects using an ORM with a persistent context (long conversation). So if I want to have menu commands defined on those database resources, I can certainly do so but I often need to calculate the application-level logical object so I can perform operations on the group, et

Eclipse has a Table widget. The widget is fairly simple like most widgets, and jface viewers and other managers are needed to make it easier to use. This is a much different strategy than .Net's Form framework where everything is built into the object(convenient but the design is not always great). The one thing I learned is that for column layout management, you can use a TableColumnLayout object. The TableColumnLayout object helps manage columns but allowing them to have a weight, minimum size, etc. While not hugely robust, it does allow you to not have to set resize listeners on the table object and then manually layout the columns. The only caveat is that the TableColumnLayout layout object must be used on a Composite that has a single child-the table. Here's a link to an example .

Eclipse has a TextActionHandler class (that uses the action framework) to handle global edit actions such as cut, copy and paste. This class has a hook for adding Text controls to it and when the text control is activated (because you have selected it or are editing it) it automatically translates the global edit actions to actions on the Text control. For application areas where you want the logical concept of the "delete" command to translate into something you want to do, for example, delete the currently selected domain object in a master list table viewer, you need to connect to the global command. The standard way has been to obtain the part site (editor or view) then use setGlobalActionHandler() to a locally defined action that then executes your logical "delete" command. Now, with the command framework, you can define a local IHandler object and using the IHandlerService obtained from the getEditorSite().getService(IHandlerService.class) method, you link

The next challenge I have is how to define a toolbar menu in the plugin.xml folder, for example, to define toolbars for Sections or other widgets capable of having a toolbar (not just the main workbench page) but still pull that definition and instantiate it for my specific view or editor part such as the section. The issue where I don't see how it works is if I define it in the plugin.xml how to do I ensure that when the toolbar needs to be created from that XML specification, that it has the right parent is used such as my Section object in an editor. The standard menu examples (eclipse 3.3) all seem to assume that it is the main workbench window page that has the toolbars and menus, except perhaps those view specific popup menus and such. Like the popup menus, I need to ensure that the right parent is used to create the toolbar. The key to the story is the IMenuService which is accessible off the workbench (not the window). The menu service off the workbench IMenuService servic