hi,
> > 1. We might need to consider the appropriate scope of the content when > deciding what custom doclet tags to use/require. A large number of > custom tags could create SoC issues from a document management point > of view. In other words, do you really want a content editor tinkering > around with java source files? no, the developer must write these javadoc tags, > > > 2. I assume we'd have tags for content like action parameters and > configuration details and their meaning? see http://members.a1.net/berni_huber/solutions/cocoon-javadoc-tags.html for starting list > > > 3. We should make sure users can generate similar content/docs for > their own custom components, particularly if they manage/maintain > their code outside the scope of the cocoon distribution. a single, or per-component xml-document is generated, see for example RequestAttributeGenerator, http://members.a1.net/berni_huber/developers/generators-ref.html#org.apache.cocoon.generation.RequestAttributeGenerator and section Parameter, and HttpRequestAttribute, these tables are generated via @cocoon:parameter, and @cocoon:http-request-attribute javadoc tags, see http://members.a1.net/berni_huber/developers/actions-ref.html#org.apache.cocoon.acting.LangSelect for an deprecated action sample But perhaps, all this reference stuff is only one aspect of the documentation.... bye bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
