I think I see it. The grey shaded bit is the 1st level inline docs you
mentioned. Looking thru some of the generated doc I'm thinking that just
having links to the nested element doc will be better than having it
inline. In the compiler tasks for example there are 3 instances of
fileset - sources, resources and references. Having the fileset doc
embedded 3 times is a little redundant.
Criticisms out of the way - this is great work. This will greatly
improve the usability of our generated doc.
Ian
Ian MacLean wrote:
A small question - required attributes in red text ? This is a bad
idea. Red makes it look like these attributes should be avoided -
'Warning'
also it seems the stying is a bit wacky. Should those nested element
sections be shaded in grey ?
and what is the 2nd paramaters table for ? did that get added by
mistake ?
Ian
Scott Hernandez wrote:
I have done a little work on the userdocs.
I have made the following changes:
1.) Reworked the Nested Elements section to include inline docs for
level 1 (it doesn't inline all docs down the chain, but just the
first one) and links to the full docs
2.) Reworked the Attributes section reordering the properties and
formatting based if they are required and are declared for the task,
or from an ancestor.
3.) Documented support types that are used as Nested Elements of
Tasks and Types.
4.) Separated Tasks, Types (globally declarable from DataTypeBase),
and Elements into sep directories
These are were serious changes to the process (how the information is
generated at the code and xslt level) and we need a long look for
style and to make sure all the content is still there. I have put up
a nightly build from the latest source.
Please look at the new form of the docs here:
http://nant.sourceforge.net/skot/help/ and compare them to the
nightly build http://nant.sourceforge.net/nightly/help/
Here is a good example of the changes:
http://nant.sourceforge.net/skot/help/tasks/foreach.html
http://nant.sourceforge.net/nightly/help/tasks/foreachtask.html
Please feel free to correct any typos or mistakes in source control,
or post a patch if you don't have commit access. I will be working
more on this, and on creating some metadata classes to ease the
development of looking at our task, type and element information. We
need classes to help us with xml validation/loading, schema
generation and documentation. Right now these processes all use the
same type of code, but with significant changes, that may lead to
differences (and probably already do) in our xml loading and
documentation (html and xsd).
Thanks,
Scott
PS. I wanted to get these change up earlier than later so we can
discuss any additional changes before I finish coding :)
PSS. There are some bad links on types.html that I already know about.
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The
Enterprise Linux in the Boardroom; in the Front Office; in the
Server Room http://www.enterpriselinuxforum.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; in the Server Room
http://www.enterpriselinuxforum.com
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
