ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Burton" <>
Subject Re: XDocs Proposal: sample HTML output!
Date Fri, 01 Mar 2002 20:51:00 GMT
Hi Erik,

----- Original Message -----
From: "Erik Hatcher" <>
Date: Friday, March 1, 2002 6:52 am
Subject: Re: XDocs Proposal: sample HTML output!

> I've applied your patches - many thanks!  I'm glad this "little" 
> proposal is being seen, used, and patched by others.


> ----- Original Message -----
> From: "Bill Burton" <>
> > Attached (hopefully) is a generated HTML version of the uptodate 
> task.  In
> > the parameters table, I threw in the type just to make it more
> > interesting.  It would have been fairly easy to make it only 
> show the
> > class without the package but handling of types would be better 
> done in
> > the XDoclet Ant support classes.
> Yes, figuring out what to do with types is certainly at the 
> AntTagsHandlerlevel when we decide how it should be done.
> > One of the big things currently missing from the XML is the 
> parameters for
> > nested elements aren't getting generated so only the description 
> can be
> > displayed.  For a rough idea of what output could look like with
> > parameters, go to
> > 
> and scroll
> > down to the "Parameters specified as nested elements" section 
> and look at
> > the "tool" element.
> Agreed.  Any suggestions on how to handle this?

Just a few thoughts below ...

> What we need is similar XML generation for the datatypes out there 
> as well as any classes used as nested elements by tasks.  I know 
> nothing of DVSL or how easy it would be to incorporate that kind 
> of info if you had another XML file describing those paramters.  

Pretty easy.  Similar to Anakia, a one line call can pull in some other
XML file.  The original stylesheet I started with did this to load
project.xml which defined the navigation menus on the right side.

> And I have a feeling it won't be trivialwork at the XDoclet/tags 
> handler/subtask level to dynamically figure out what the nested 
> elements are and the process those - but that seems where we
> need to go with it.  

Yes.  If there's not any easy way to do it, then maybe classes defining
nested elements will need to be tagged something like, @ant:element ...

> Then we have sub-elements of sub-elements, 
> and so
> on......

I wouldn't worry about the nesting for now.  Just generate all
<element>'s at the same level.  The doc comments will likely already
desribe the nesting.

> For global datatypes that are nested elements, I don't think we 
> need (or want) to display the parameters for them, just hyperlink 
> to their own documentation.

Yes. I don't see this as a problem.  Eventually, if there's some way
these could be identified in the XML, this could be used to pull in some
canned doc from the appropriate datatype XML as you describe above.  

> Again, thanks for your work on this - its coming together nicely.
>    Erik

You're welcome.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message