[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[tigerstripe-dev] Tigerstripe skeletons
|
Following on
from my
action point in the Tigerstripe call.
When we want to
produce skeletons, we are talking about two possible areas:
a) Java class or
interface files.
b) ecore definitions
for new Annotations.
a) Is pretty
straightforward
We can do this a variety of ways including Velocity templates, or though
some utility stuff in JDT. I think the latter is sufficient - there is very
little "injection" of information needed - ie the velocity template might only
have class name and imported Annotations as the only variables - thus making the
overhead of plum,bing the framework together a bit OTT. I think the key thing
here is not how we create the files, what we want to put in
them.
At the moment as
long as you implement an interface, most extension points are satisfied. This
leaves a lot to be done in terms of implementing methods. I think we should come
up with one (or more?) Standard Implementations that allow us to add simple
Audit Checks for example, based on the presence or absence of Annotations on
certain model objects. A similar approach would probably work for Label
Decorators etc.
We could implement
some (very simple) wizards that prompt the user to see if they want to use this
basic pattern, and then to capture the necessary details. If they want to go
more freestyle - they are on their own - so we just provide a very basic
skeleton file.
Issue: I think we
also need to be able to add to existing audits etc as we add new annotations,
rather than just have yet another audit class?
b) Is less
simple.
We can create an
ecore from a set of wizard inputs that define a new Annotation. That much is not
very difficult.
Sadly we then need
to create the genmodel - and potentially set some attributes in that
before then going on to do the actual creation - that might be a bit
harder?
We also need to be
able to edit an existing ecore and do these steps.
I agree that this
would probably be valuable to allow Annotation definitions to be presented in a
more intuitive manner than the basic ecore editor. It might be considerable
effort to maintain it as a generic tool - we have no idea how complex we want
out Annotations to be.
Anyone have any
guidance on where the most value lies - I know John in particular felt that
defining the Annotation in ecore was a big pain.
I am proceeding with
some efforts to create at least basic java for now.
RC
"This e-mail may contain confidential
and privileged material for the sole use of the intended recipient. Any review,
use, distribution or disclosure by others is strictly prohibited. If you are not
the intended recipient (or authorized to receive for the recipient), please
contact the sender by reply e-mail and delete all copies of this
message."
"Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square, Cardiff,
South Glamorgan CF10 5BT"