Live file template question

Is there a way to coerce a live template to spit out a list of method input parameters? (Just names, not necessarily values).

Somehow, I'd like to end up with a String representing the signature of the method (sans visibility modifiers). Just something like:

"return_type method_name(input_param[, input_param...])"

The method name is easy, but the return type (which I could live without) and input parameters have me stumped.

4 comments
Comment actions Permalink

You'd probably have to write a plugin to do this.

0
Comment actions Permalink

Hi,

Michael Campbell wrote:

Is there a way to coerce a live template to spit out a list of method input parameters? (Just names, not necessarily values).

Somehow, I'd like to end up with a String representing the signature of the method (sans visibility modifiers). Just something like:

"return_type method_name(input_param[, input_param...])"

The method name is easy, but the return type (which I could live without) and input parameters have me stumped.


I'm not sure what the use case is, but if having it as a LiveTemplate is
not essential you might consider using xDoclet for this.

It's taken me a couple of days to get up to speed with it but it works
well with the built in ANT support and can solve this kind of problem.

Off the top of my head a chunk of a template to generate what you are
looking for might look like:

<XDtClass:forAllClasses>
<XDtMethod:forAllMethods>
<XDtMethod:methodType/> <XDtMethod:methodName/>(
<XDtParameter:parameterList/> )
</XDtMethod:forAllMethods>
</XDtClass:forAllClasses>

you would then configure the ANT task in terms of where you wanted the
data put and which classes it should consider.

Regards,

Matt

0
Comment actions Permalink

Thanks Matt, that's food for thought.

My plan was live file template specific, however. What I wanted this string for was to be used in some tracing code, although I supposed I could use the XDoclet approach, put the output into a .properties file with some sort of generated key, and put the key into the call to the logger...

Hrm. Thanks, I'll ponder this a bit.

0
Comment actions Permalink

Michael Campbell wrote:

Thanks Matt, that's food for thought.

My plan was live file template specific, however. What I wanted this string for was to be used in some tracing code, although I supposed I could use the XDoclet approach, put the output into a .properties file with some sort of generated key, and put the key into the call to the logger...


My experience with xDoclet has been generating configuration files for
use with the Dynaop[1] aspect framework.

Dynaop can be configured at runtime using BeanShell[2] scripts which are
effectively loosely (or more Lisp like, optionally) typed interpreted java.

In this case the scripts call methods which Dynaop injects into the
interpreter space and which allow the script to register interceptors &
mixins. I've found it to be an very powerful approach.

Now I have xDoclet templates building the beanshell scripts that
configure both Dynaop & my own application.

Again it's probably not what you had in mind but you could expose your
tracing interface to Beanshell and have xDoclet generate a configuration
script which registers methods with the trace code at run-time.

Using xDoclet would allow you fine control at class, method, or field
level using javadoc comments.

Regards,

Matt

http://dynaop.dev.java.net/
http://www.beanshell.org/

0

Please sign in to leave a comment.