> It sounds really cool.And I can imagine that thos
> approach could be usefull common xml generation/
> parsing/processing tasks...
> ( XTags? )
>
Yup, the engine is generic. It generates a Velocity template. That
template will access java beans. These beans are generated too (well,
the interfaces are).
So we can pass the xtags.dtd file to xgg and get the template and the
bean interfaces generated. Then we can implement these beans, and they
will acces data from "somewhere".
-But where is this "somewhere"? Is it from @tags/xjavadoc? Is it from
properties files? Is it from many smaller XML files? -I don't know yet,
but I'm sure we'll come up with a format that fits the purpose.
How would you describe a single tag? If we go for an approach where a
@foo.bar tag corresponds to a xdoclet.modules.foo.tags.Bar class (that
could implement some xdoclet.tags.Tag interface), it would be sensible
to put the info that will go into xtags.xml in @tags. Example:
/**
* @xdoclet.tag
* name="foo.Bar"
* level="method"
*/
public class BarTag implements Tag {
/**
* This is a tag attribute (aka 'parameter')
*/
public String getZap()
}
Then, when xtags.xml is generated with xgg, people can use this tag:
/**
* @foo.bar zap="gurba"
*
public void doIt();
Am I completely off track here, or could this approach be useful in
xtags?
Aslak
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
