Sounds to me like you are on the right track! Possibly there should be a switch on ModuleDescriptorParser to have it ignore descriptions except when parsing for HiveDoc.
I had been thinking in terms of an XMLWriter interface (similar to Tapestry's IMarkupWriter). This would allow easy XML output with methods like begin(), attribute(), write() and end(). A second interface, XMLWritable, woudl be implemented by the various descriptor objects, i.e. public void writeXML(XMLWriter writer); What's your solution shaping up as? On Wed, 13 Oct 2004 16:26:42 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote: > Update. I've now implemented the HiveDoc generator as described in > the previous message. The limitations are still: > > - not all schemas are generated into HiveDoc > - <conversion>s are displayed as their <rules> equivalent > > The first limitation could be solved by simply adding a getter to the > RegistryAssembly. However, I think it might be cleaner if the > Descriptor objects would retain the distinction between defining a > schema and referencing an existing schema. I.e. the > ConfigurationPointDescriptor could be changed from: > > public Schema getContributionsSchema(); > public void setContributionsSchema(Schema schema); > > to: > > public Schema getSchema(); > public void setSchema(Schema schema); > public String getSchemaId(); > public void setSchemaId(String schemaId); This can also affect ServicePointDescriptor (parameters schema). > > That's making the Descriptor classes more complex. But on the positive > side I think it should then be possible to remove the dependency on > RegistryAssembly in DescriptorParser (and thus also in > ModuleDescriptorProvider). The RegistryAssembly is only used to > resolve schema references (using SchemaInjector), which wouldn't be > needed anymore. Thoughts on this? > > The second limitation can probably be addressed by inversing the > dependency between ConversionDescriptor and ElementModelImpl... > somehow :-) Shouldn't be too hard to create a ConversionDescriptor or somesuch. I wrote it the way I did to limit the amount of new code I needed to test. Requirements change; here there's a requirement to allow reproducability to XML. > > --knut > > On Wed, 13 Oct 2004 13:35:52 +0200, Knut Wannheden > > > <[EMAIL PROTECTED]> wrote: > > I've started implementing a HiveDoc generator which gets its input > > from ModuleDescriptorProviders instead of reading the XML module > > descriptors. This should allow HiveDoc being generated for module > > descriptors defined in other formats. > > > > The strategy of the implementation is to assemble a single XML > > document equivalent to that which the <createregistry> task creates > > and then feed it to the existing XSLT to generate the HiveDoc. Maybe > > this strategy should be changed in the future, but for now I think it > > should be the easiest approach. > > > > This implementation requires many of the Descriptor classes to be > > extended. Most obvious is a new "description" field. There are also a > > few cases where the Descriptor classes don't provide a getter. All > > this should be easy to fix. > > > > More problematic is: > > > > - <schema>s are not added to the Descriptor defining them. Instead > > they're directly linked to the elements using them. But this leaves > > out any unused schemas (e.g. "hivemind.lib.Pipeline"). > > - A <conversion> element is "unwrapped" and cannot be distinguished > > from its <rules> equivalent. > > > > Anyone got thoughts on this? > > > > --knut > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
