[news.eclipse.tools] Re: Code Templates - Contexts and re-use

[Claude Knaus <Claude_Knaus@xxxxxxx>]

Mikko,

Mikko Kamarainen wrote:
> 
> Starting to make my own code templates (an excellent feature in Eclipse
> BTW!) and this came to mind: now there seems to be 2 possible contexts for
> templates: java and javadoc - but how about 1) more general (non java)
> contexts and 2) subcontexts?
> 
> 1) more general context - user-definable: xml, jsp, html etc. - according
> to file type - this can now be accomplished by defining java or java
> scrapbook editor as the default editor for such a type and defining the
> templates under java context - but then they are in the wrong place...

I'm thinking of this already...

> 2) the more complex the templates get, the more one could use hierarchical
> contexts - once a template has been selected, it could be nice to have
> sub-templates that only apply within the selected template. I'm thinking: a
> XDoclet template -> under this context one sees only the tag-templates like
> ejb:bean name="${name}".. or @jboss:... etc.

I'm not sure I understand what you mean by sub-templates. If the (sub-)
context
matches sufficiently well, you should only see the templates appliyable
at 
the position you issue the code completion. I don't see a need to
introduce
something like a menu structure...
I know, at the moment the contexts does not check if a template is
'truly'
applicable at the code completion position, but this will hopefully
change 
in the future.

> Also, can someone think of a way to add the following functionality to
> templates:
>  - description for variables for the user: @ejb:bean name="${name}" - the
> name could have the description from XDoclet docs.
>  - simple choosing from a pre-defined list for the value of a variable like
> true/false for @ejb:bean generate="true/false"
> 
> After that I only need to figure out how to get XDoclet to run under
> Eclipse - now the built-in ant fails where the same build.xml runs fine
> externally...

The problem with these kinds of 'smart' variables is that they require
enough public API to evaluate themselves. Like many people requested,
they'd
like to have the class name as a variable, which is currently not easy
to do.

It's possible that user definable contexts along with their variables
will become public (via extension points), but first the infrastructure
has to be there (I'm working on it). Currently, it's still tied too
closely
to Java.

Anyway, thanks for the feedback!

-- Claude