ok, so we'll have some data object store access (ProjectStore, BuildStore...) and DefaultContinuum
will use them. Webwork actions will use them too or they'll use Continuum interface?
Emmanuel
Brett Porter a écrit :
+1
I'm all for splitting up into action components, but retaining a
Continuum interface as a single entry point to those
- Brett
John Casey wrote:
I think we have to be careful when splitting up a public api like
this. It's possible Continuum may need to be embedded someday, and if
so, it would be much better to have a single interface for controlling
it...even if it means that interface delegates most of its work. While
I think you can probably factor out a lot of the actual logic, we need
to preserve that coherent, single-interface accessibility IMO.
Besides, we do still have to maintain public API compatibility, since
it's only a x.y release...
My 2 cents.
-john
Emmanuel Venisse wrote:
Hi,
I'd like to know your opinions about the continuum refactoring for 1.1
What we'll do?
Replace plexus-summit/velocity by JSP/WebWork/SiteMesh
What i'd like to do?
Actually, DefaultContinuum class is our centralized code class. With
a framework like webwork, i think we can improve the architecture by
splitting it with this :
- all data manipulations (CRUD) will be in several DAO classes
- all utility methods (is*InQueue, checkoutProject, buildProject*
will be in several utility classes (or action classes in webwork terms)
- in DefaultContinuum, we'll keep only initialization methods
With this refactoring, i think it will be more easy to migrate to
webwork, and maintenance will be more easy.
WDYT?
Emmanuel
