RE: [Xdoclet-user] Custom Template Tags

[Ara A. <ar...@ya...>]

Good points. The docs aren't that good really. Probably because it's a
moving target. This list is a good place to share experiences.

Ara.

> -----Original Message-----
> From: xdo...@li... [mailto:xdoclet-user-
> ad...@li...] On Behalf Of Brian Topping
> Sent: Saturday, July 27, 2002 5:45 PM
> To: Charles Daniels; xdo...@li...
> Subject: RE: [Xdoclet-user] Custom Template Tags
> 
> Chuck,
> 
> I'm just getting started with creating templates and tag handlers too,
> here
> is some additional information that might be helpful.  I think most of
> this
> is correct, but if I am way off base, hopefully someone can pitch in
and
> we'll both learn something ;)
> 
> You might know all this already, so FWIW..
> 
> * As Ara stated, the tags that exist already probably shouldn't be
> overridden
> just because you could have undesirable effects on other templates in
the
> system.  And you probably shouldn't override the classes because then
you
> will be susceptible to fragile base class problems for when the rest
of
> the
> source base changes.  Better to copy the code into your own module as
you
> need to change it.
> 
> * There is an 'architecture.html' document in the build and online.
It's
> worth rereading both of these (over and over again ;) as you get a
better
> understanding of the code.  Some of the nuances of the code aren't
> repeated
> twice in these docs, so some stuff will be suddenly obvious where you
> didn't
> even notice it before.
> 
> * With that in hand, getting started on your own module is pretty
easy.
> Take
> a smaller one (such as webwork), duplicate the directory (minus the
CVS
> directories), then change the 'webwork' to whatever wherever it shows
up
> in
> there.  You can snip all the methods out of the TagHandler file (since
you
> are writing your own) and if you aren't adding any ant options, you
can
> often
> trim down the DocletSubtask class pretty good as well.  The build.xml
> automatically gets included in the master build, and as long as you
update
> the namespace tag at the top of the TagHandler, you'll be reachable
from
> the
> template.  Then start generating your own tags.
> 
> * Some stuff like what you are doing might not be worth adding another
> project for.  You just have to decide whether you are going to submit
it
> or
> not, and if not, whether you want to deal with merging changes from
CVS
> whenever the file changes up there.  Since you can mix between modules
> within
> a template, it's not a big deal to keep a separate module of your own.
> 
> * generate() is recursive, everything is a string
> 
> * Note the use of how the attributes are passed in a hash.  It's
helpful
> to
> know this.
> 
> * There are a lot of associations set up about the entire code tree
that's
> been processed before your template gets a chance to operate.  This is
> especially important with stuff like container-managed relationships
in
> the
> 2.0 entity beans.  The names that are used are the keys between both
sides
> of
> the relationship.  Look very closely at the patterns like this in the
> sample
> code.
> 
> I've been working with Xdoclet for a couple of months now and I am
still
> finding stuff in it that blows me away.
> 
> hope it helps,
> 
> -b
> 
> > -----Original Message-----
> > From: Charles Daniels [mailto:cj...@ya...]
> > Sent: Friday, July 26, 2002 1:12 AM
> > To: xdo...@li...
> > Subject: [Xdoclet-user] Custom Template Tags
> >
> >
> > Hi all,
> >
> > I apologize if my question has been answered somewhere on the
> > list, but I can't seem to find the
> > answer.  I would like to know how to install a custom
> > template tag.  I want to extend the
> > MethodTagsHandler so I can add a couple of methods.  One such
> > method is titleCaseMethodName, which
> > would be nearly identical to the method methodName except
> > that it would return the method name
> > with the first letter of the method name converted to
> > uppercase.  The reason I want to do this is
> > because I want to generate a class file with method names
> > that add a prefix to the names of the
> > methods in a given interface.  For example, I want to
> > generate a class named XxxFilter based on
> > the Xxx interface.  For each method, named mmm, in interface
> > Xxx, I want to generate a method
> > named filterMmm in the XxxFilter class.  So a snippet of my
> > template for generating the methods
> > might look something like this:
> >
> > <XDtMethod:forAllMethods superclasses="true" sort="true">
> >     public void filter<XDtMethod:titleCaseMethodName/>()
> >     // other stuff omitted
> > </XDtMethod:forAllMethods>
> >
> > Therefore, how do I plug in my extension of MethodTagsHandler
> > for xdoclet to use?  I know that the
> > default handlers are specified in the tagmappings.properties
> > file in xdoclet.jar, but how do I
> > override a default?  I imagine that I don't want to modify
> > the tagmappings.properties file in
> > xdoclet.jar.  Furthermore, is my intended approach the best
> > way to achieve my goal?  Any guidance
> > is greatly appreciated.
> >
> > Thanks,
> > Chuck (xdoclet newbie)
> >
> > P.S. xdoclet is awesome!
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - Feel better, live better
> > http://health.yahoo.com
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Xdoclet-user mailing list
> > Xdo...@li...
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-user
> >
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Xdoclet-user mailing list
> Xdo...@li...
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user