DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131 [PATCH] XMLModule: Allow XPath access to arbitrary XML sources Summary: [PATCH] XMLModule: Allow XPath access to arbitrary XML sources Product: Cocoon 2 Version: Current CVS Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, Attached is an XMLModule input module, that allows XPath access to any XML document, specified as a Source. The code is very simple, building on AbstractJXPathModule. It is pretty powerful though, because it can access XML from *any* Source. So you can access: - static XML (context://..) - XML generated dynamically by the sitemap (cocoon://) - XML retrieved from HTTP (http://..), Xindice, any other source.. you get the picture. As a stupid example of what you can do, here's how you could access Slashdot headlines from a sitemap: // In cocoon.xconf: <component-instance class="org.apache.cocoon.components.modules.input.XMLModule" logger="core.modules.xml" name="slashdot"> <config>http://slashdot.org/slashdot.rss</config> </component-instance> Then access the first headline with: {slashdot:/*:RDF/item[1]/title} A less stupid example: accessing a Forrest config file: // cocoon.xconf <component-instance class="org.apache.cocoon.components.modules.input.XMLModule" logger="core.modules.xml" name="myxml"> <config>context:///samples/modules/forrestconf.xml</config> </component-instance> The file is now accessible with variables like: {myxml:/forrestconf/@version} {myxml://skin} The patch includes modifications to samples/modules to demonstrate the XMLModule. I also modified AbstractJXPathModule slightly, to allow subclasses' getContextObject() method to throw ConfigurationExceptions. One issue is caching: XMLModule doesn't do any. It is thus horribly inefficient, doing a Source resolve and XML parse for every variable lookup. I'm not sure how to fix this. Is it XMLModule's concern or AbstractJXPath's? Would caching the JXPathContext help? Would XMLModule just do a lookup of the MRUMemoryStore Component, and store Source objects in it, and generally manage caching by hand? Um. --Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
