[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tigerstripe-dev] Tigerstripe skeletons

Title: Re: [tigerstripe-dev] Tigerstripe skeletons
Hi Richard,

It seems that .ecore creation for annotations is not something that will be done very often. If we take the example of trying to “dress-up” Tigerstripe through the annotation framework, I doubt you’d do that very often. So, the definition of the annotations doesn’t sound too bad to me.

Being able to generate code fragment “per annotations” may be more interesting? Like a decorator for a given annotation?

Anyway, based on what you are describing below for the Java/XML generation we should be able to leverage that easily in future development.


On 3/19/09 10:16 AM, "Richard Craddock (rcraddoc)" <rcraddoc@xxxxxxxxx> wrote:

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.


"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"

tigerstripe-dev mailing list