Hi Erik, ----- Original Message ----- From: "Erik Hatcher" <[EMAIL PROTECTED]> 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. Thanks! > > ----- Original Message ----- > From: "Bill Burton" <[EMAIL PROTECTED]> > > > 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 > > http://jakarta.apache.org/velocity/dvsl/ant_task_reference.html > 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. -Bill -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
