Ted Husted wrote:
I'd suggest showing how to hook up to iBATIS or HIbernate in an example application, and then deciding if TI needs to create yet-another DAO framework. Many iBATIS user s have stopped using the iBATIS DAO framework, since they find using a dependency-injection framework, like Spring, works as well or better. Most DAO implementations are specialized cases of dependency injection. If you are already using Spring and interfaces, the value of a standard DAO framework is diluted, since you can always have Spring (or the equivalent) load an alternate implementation. The same is true if you are using CoR. If some of your commands are data-access commands, you can load an alternate data-access set by changing Catalogs. Life becomes very sweet when you use both Spring and CoR (which is what we do at work). We use Spring to load the Catalog, along with whatever other objects we need.
Agreed. Since Spring is directly built into Ti, it would make sense to recommend its use for a DAO structure. If Ti had a secondary goal, it would be to use what's out there whenever possible. Even if the integration is ugly under the covers, as long as it is smooth and seamless to the user, that's all that matters.
You might also be interested in the Spring and Chain integration piece I wrote for Ti. Basically, I first lookup the chain command name as a Spring bean, and if not found, then instantiate the command from the className attribute like normal. This lets me inject all sorts of goodies into commands that Ti uses. In particular, I use it to inject servlet-dependent implementations of interfaces so that the chains can remain servlet-independent.
http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/ti/jars/core/src/java/org/apache/ti/processor/chain/chain-config-servlet.xml?view=markup Don
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
