Duh - sorry. My point was that the "http://appfuse.org/display/APF/AppFuse+Core+Classes"; approach is not so bad as I thought at first. It only involves expanding 5 domain/model classes and a constants class into my source tree. I will keep the "org.appfuse" package names for these 5 domain objects, but use my "com.acme" package for all of the domain objects I create.
And if necessary I will create any required extensions to the Appfuse BaseObject/User/Role/Address/LabelValue DAO and/or manager objects in my "com.acme" packages. Comparing against upgrades to appfuse in the future should be relatively easy. Any other thoughts? > [EMAIL PROTECTED] wrote > Yes, and I guess that's what I'm going to do. The next thing I'll need to > do is add finders to the DAO or logic to the manager. > > But, there's no reason I cannot just use standard Java inheritance to > build on top of the com.appfuse DAO and manager objects from my own > extensions. At least that's the tack I am taking now. > > Thanks! > > > mraible wrote: >> >> If you only want to modify domain objects, you can do that too: >> >> http://appfuse.org/display/APF/AppFuse+Core+Classes >> >> Matt >> ... >> > > -- View this message in context: http://www.nabble.com/Better-way-to-modify-User-UserDao-UserManager-tp14499981s2369p14586905.html Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
