[Registry-dev] Aspects UI

[Glen Daniels]

Paul Fremantle wrote:
> I think it might be useful to explain the concept a bit more. I'd also 
> like to see the Heading retain the word lifecycle. How about
> 
> "Lifecycles and Aspects"

"Aspects / Lifecycles" is OK with me, although yes it suffers a little 
in a "purity" sense. :)

Re: explaining the concept, I'm working on framing a draft document now.

> Here is my attempt to explain this, and correct me if I'm wrong:
> 
> * An aspect is just simply a way of associating a combination of some 
> state and an action with a resource.

An aspect is a way of associating custom actions with a resource.  At 
core, that's it.  If an aspect has any notion of state, that's entirely 
custom depending on the implementation of that aspect (i.e. how it 
chooses to use properties/resources is it's own business).  So the 
takeaways here: 1) it's not necessarily state, and 2) it's potentially 
more than one action.

> * So a lifecycle is a state e.g. {created, tested, deployed, deprecated} 
> together with one or more actions {demote, promote}

That seems like a pretty good definition for now.

> I think we need to display the "state" next to the aspect. In other 
> words, at the moment the lifecycle state is independently displayed in 
> the properties. But of course this isn't necessarily clear.

Paul and I had an IM conversation about this, in which I noted that 
Aspects don't necessarily have state so this kind of thing doesn't make 
sense for all Aspects, though it clearly does for Lifecycle.  So my 
suggestion was to have:

class Lifecycle extends Aspect {
   public abstract String getState();
}

And then in the UI we could say "if (aspect instanceof Lifecycle) 
[display the state]".

We also discussed having a "StatefulAspect" which could capture this 
behaviour, and then lifecycles (and other things) could extend/implement 
that, which I'm OK with too.  So if option 1 is the above, option 2 
would be:

interface StatefulAspect {
   String getState();
}

Thoughts?  IMO this is eventually going to evolve into mini-custom-UIs 
for Aspects that wish to display information or have richer behavior 
than just "do it", but for now this kind of "just display the state" 
thing seems ok.

> Secondly, I'd like the default lifecycle handler to pick its states from 
> a file (or better still from somewhere in the registry), so that a user 
> can edit them for his/her own company model. I also think it needs more 
> than just "promote". Maybe "promote" and "reset".

+1, it's a cool idea, but I think this is post-1.1 at this point.  We'll 
add it to the list as a nice-to-have, but the goal of 1.1 is really to 
get the mechanism solid and provide a good example of how to use it. 
This kind of non-code-based state machine stuff is great but it can also 
easily happen later once the framework is there.

Thanks,
--Glen