continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: short term branch for project/group keys
Date Thu, 28 Dec 2006 04:48:18 GMT

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  

> 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

View raw message