On 27/12/2006, at 8:28 AM, Jesse McConnell wrote:
Rahul is going to mail on how this can be cleaned up in the store api, but I question why we want these methods on the Continuum interface at all?
I think it's there as the application interface - for use from the webapp and the xmlrpc interface (which is generated pretty much off the Continuum interface).
I'm not a big fan of this when it doesn't have any logic of its own, but it can make sense for the external interface. As long as it isn't used within the app itself, it's a good idea - though I'd even limit it's use in the webapp in favour of the actual components which should not require any additional scaffolding if they are designed right.
My thought at the moment is to take methods like 'getBuildDefinitionForGroup' and move those to an interface for group related actions that can't be directly on the ProjectGroup model class.
It might make sense to decompose Continuum into a number of different controllers that the main one delegates to just so it isn't so mammoth.
The above sounds like a good idea as long as the getBuildDefinitionForGroup method isn't doing any logic, store interactions, or caching (ie, it's just looking up in the group object). Otherwise, I wouldn't do this.
The we would have a ContinuumGroup and ContinuumProject interface and impl that could act as facade's over the model classes and some of the other logic oriented methods that are currently in the Continuum interface.
That might make sense. Probably worth drawing it up. We definitely need to be making the architecture simpler, not more complicated.
- Brett
