uPortal IRC Logs-2007-02-07

[09:24:57 CST(-0600)] <esm> EricDalquist : i have a solution i think for the id factories
[09:33:14 CST(-0600)] <EricDalquist> cool
[09:33:18 CST(-0600)] <EricDalquist> whats the plan?
[10:53:10 CST(-0600)] <esm> heh. I should have said i think i have a solution
[10:53:16 CST(-0600)] <EricDalquist>
[10:54:18 CST(-0600)] <esm> basically have an AbstractFactory backed by a registry containing IObjectIdFactory instances
[10:54:41 CST(-0600)] <esm> spring builds the registry and provides it to the AbstractFactory
[10:55:25 CST(-0600)] <esm> clients query the AbstractFactory using something like AbstractObjectIdFactory.createId(int, Class)
[10:56:08 CST(-0600)] <esm> the AbstractObjectIdFactory looks up the corresponding IObjectIdFactory from the registry using the Class as a key
[10:56:33 CST(-0600)] <esm> invokes createId(int) on the factory from the registry and returns
[10:56:49 CST(-0600)] <esm> i'm working on code and testcases now
[10:58:14 CST(-0600)] <esm> basically all the existing objectidfactories and objectid interfaces won't change. The clients of the factory will need to be updated to use the new uber-factory but that should be pretty easy to do
[10:59:21 CST(-0600)] <esm> this will have the net affect of decoupling the *-api maven 2 artifacts from their corresponding impls, because the uber-factory will return interfaces only
[10:59:51 CST(-0600)] <esm> clear as mud? sorry if i'm not explaining well. I'll write some code and you see what you think.
[11:18:03 CST(-0600)] <EricDalquist> sounds great actually
[11:33:36 CST(-0600)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has joined ##uportal