Ok, first set of changes have been committed for anyone who wants to
take a look.
Most of the re-architecting has been done now and I have begun cleaning
up the things that got broken in the process. So far I have cleaned up
pretty much all of the basic stuff, including operations on users,
roles, websites, permissions, and website templates.
The next things I'll be cleaning up will be pings, weblog contents
(entries, categories, bookmarks, comments, referers), and then the
planet manager.
-- Allen
David M Johnson wrote:
On Apr 5, 2006, at 12:53 PM, Allen Gilliland wrote:
I have a couple additional changes that I think should be part of this
process ...
1. Remove some old classes.
2. Remove user role CRUD methods from UserManager
3. Remove PersistenceStrategy interface.
after beginning to work on the backend refactorings i found that the
PersistenceStrategy was actually causing some problems because even
though it is meant to be simple it forces some of its own ideology
about how persistence should be implemented. in particular the
PersistenceStrategy methods do not identify what the transaction
strategy for those methods are, meaning are they commited after being
called? or not? and since the abstract manager impls actually use
those methods there is the potential for a mixup.
my belief is that the implementor of a given backend implementation
should be allowed to do persistence any way they want, as long as they
fully implement all the methods defined in the manager interfaces. so
for this reason i think it makes sense to not force the use of the
PersistenceStrategy.
keep in mind that this is a little hard to describe and i believe it
becomes a little more clear once you get into the code and see what is
happening. also note that i still intend to keep a
HibernatePersistenceStrategy class because it does fit nicely with a
hibernate implementation, but it is more like a Hibernate utility
class rather than a required part of all persistence implementations.
All sounds good to me.
At this point, the PersistenceStrategy is just a thin wrapper and I
don't think it buys us much in supporting multiple implementations. So,
no objection here.
- Dave
