On Wed, 13 Oct 2004 11:33:14 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > 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); >
Or how about a more general purpose DescriptorVisitor interface and corresponding visit(DescriptorVisitor) methods on the Descriptor classes? This visitor could then also be used by the RegistryBuilder. > What's your solution shaping up as? > The approach I had in mind was to begin with implementing an alternative <constructregistry> task. This task would get the ModuleDescriptors from the default XmlModuleDescriptorProvider and build up the XML document by traversing the Descriptor tree. > 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 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 have now solved this by letting ConversionDescriptor implement the Rule interface. The calls to begin() and end() just delegate to the CreateObjectRule, ReadAttributeRules, and InvokeParentRule. The twist is just that the <conversion> is not really a rule (it's not nested in <rules>), but the purpose of the two is a common denominator. It's just the term that's missing. Currently the implementation just doesn't generate HiveDoc for unreferenced schemas yet, otherwise it is feature complete. Once I have solved that I'd like to commit the implementation as a first iteration to CVS. Then we can take a look at the refactorings we've discussed. Sounds good? --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
