The approach we had taken with the portlet objects in the 3.0 work was to have Dao and Registry objects. The DAOs focused on just CRUD based operations and the registries provided higher level functional like 'get or create' that could end up using multiple DAO methods. Also since the JPA managed objects have their own caching all client code always goes back to the registry for the objects, they are never stored in places like a user's session only IDs are stored there.
I'm excited to see this work being proposed, it would be great to get even more referential integrity added to the portal database and replacing the old bare JDBC code with something a bit higher level.
Thanks for the great write-up, -Eric Drew Mazurek wrote:
Hi everyone... for those of you who don't know me, I'm Drew Mazurek, currently working as a programmer for Unicon's Cooperative Development program. I worked for Yale University's Technology & Planning group for four years, and in my time there I was the Yale CAS project lead as well as the author of the official CAS protocol specification.Some of the work I've done for Unicon on UP-2047 is checked into the 3.1 trunk. Specifically, I created the new Spring-backed JSON groups and categories service (UP-2394), wrote the subflow for the groups selector webflow (UP-2171), and added UP_PERSON_DIR info to the import/export tool (UP-2189).I've been tasked with working on refactoring the channel registry, and through discussions with my Unicon colleagues, Drew Wills, Jen Bourey, and Gary Thompson, we've come up with the following:In going where we intend to go with UP-2047, we will soon be hampered by the current uP API for channel publishing and management, which is IChannelRegistryStore + ChannelRegistryManager.IChannelRegistryStore is basically the 'DAO' for channel registry information. It provides essential CRUD operations over the following types of entities:- ChannelType - ChannelDefinition - ChannelCategoryBesides unit tests, there's only one implementation of IChannelRegistryStore: RDBMChannelRegistryStore. It stores channel info in the database using the following tables:- UP_CHANNEL (channel entities) - UP_CHANNEL_PARAM (publishing parameters) - UP_CHAN_TYPE (channelType entities) It also uses the GaP API for channel categories.ChannelRegistryManager provides several static method-based utilities to perform many of these operations in XML format.For 2047, we expect that these capabilities won't be comprehensive enough to support the features we would like to offer. We will probably want to add new capabilities. In this case, it probably makes sense for us to look at "trading up" the RDBMChannelRegistryStore for a new persistence infrastructure, presumably one based on Spring+JPA+Hibernate, since that's the current sanctioned approach within the community.Looking at what's there currently, we're thinking it may be sensible to proceed by creating a new implementation of IChannelRegistryStore, such as 'JpaChannelRegistryStore.' There are many, many dependencies on the IChannelRegistryStore type in the codebase; for everything else besides the Portlet Manager we may be able to "leave well enough alone."The usual JPA pattern in uP involves creating a DAO (more accurately, an interface + a concrete class); this DAO probably *should not be* the IChannelRegistryStore impl itself.The DAO interface can and should define more capabilities than those needed for the IChannelRegistryStore impl. Our portlet can interact with the DAO directly to make use of these features.As always, we welcome the uPortal community's input on this task, and we would like to keep our development as public and transparent as we can. Please forward along any comments you may have in this regard.Thanks, Drew
smime.p7s
Description: S/MIME Cryptographic Signature
