Re: [xml-users] Overriding services provided by XMLSupport...
Petr Kuzel <[email protected]> Thu, 16 Sep 2004 10:17:55 +0200
| Newsgroups | gmane.comp.java.netbeans.modules.xml.devel |
|---|---|
| Organization | Sun Microsystems |
| Message-ID | <[email protected]> |
Neuman, Ben J., A&M IRM wrote: > Hello, > What is the best way to implement new functionality on an XmlDataObject? I > am writing a module SVG image support. This modules must allow all current > XML functionality to be applied to svg documents as well as view the > generated image. > > As far as the standard XML functionality goes, I have found two means of > applying it to SVG docs. The first is very simple, utilizing an XML Layer to > register the svg mime type and map svg docs to xml type: > > // Layer.xml section... > <folder name="Services"> > <!-- Recognize image/svg+xml --> > <folder name="MIMEResolver"> > <file name="org-netbeans-modules-svg-mime-resolver.xml" > url="mime-resolver.xml"> > </file> > </folder> > </folder> > > // mime-resolver.xml section... > <file> > <ext name="svg"/> > <ext name="svgz"/> > <resolver mime="text/xml"> > </resolver> > </file> > > The second method involves implementations of SvgDataLoader and > SvgDataObject. XML Actions and Cookies are applied in each class > respectively. Preferable approach. You have everything under control and you can use various support classes to assemble final solution. > Back to the original question... Which method should I choose to proceed > with SVG image viewing functionality? I like the first setup better, > however, I am at a loss as how to proceed from there. Is it possible to have > multiple loaders and or dataObjects applied to a file type? > I am a little clearer on how I can add functionality to my own SvgDataLoader > and SvgDataObject, but I wonder if there is a better way to do this rather > than add specific XML Actions and Cookies programmatically. Previous module owner preferred framework based solution, you can still see relicts of it, massive use of lookup and factories in XMLDataObject. But this approach duplicated code in openide.loaders. My architectural choice was to provide support classes and let extension modules that provide domain specifics functionality put it together. It gives full freedom to the extension modules. I do not know Milan's preferences. He's current module owner. Cc. PS: moving to [email protected] discussion list