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
- ChannelCategory
Besides 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
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
