While I do like the idea of splitting up any monolithic code in the
DefaultContinuum class, I don't support splitting data-access code from
itself.
IMO, breaking data-access stuff by model-class is asking for trouble,
since it doesn't allow a good mapping of data-access functions for
+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
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
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
