|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 6 of 7
<mls>
<module-uri>urn:net:bosatsu:jw-rest</module-uri>
<filter>ffcpl:/data/.*xml</filter>
</mls>
Note: This capability of fetching module-specific files can be reused and cached, just like anything else in NetKernel!
A listing of the sample XML files are returned and iterated over. Each document is fetched as a String:
cust = context.sourceAspect("ffcpl:/data/" + current, IAspectString.class);
sb.append(cust.getString());
Then each document is appended to a StringBuffer to return the results. This one call to sourceAspect underscores NetKernel 's RESTful nature quite nicely. You have a logical request (ffcpl:/data/somefile.xml), a verb (SOURCE, equivalent to REST's GET) and content negotiation. Here, NetKernel is asked to convert the file on disk into a String representation known as a StringAspect. It would be trivial to convert the request to return a byte array, a JDOM Document, a DOM instance, or any other form you might want in a different context. An Aspect in NetKernel is an immutable view of a particular representation of a resource. Because it is immutable, the whole request
can be cached until one of the input resources changes. If you do not care what form comes back, you can call the source method instead, which takes only the URI for the information resource you want.
Once the StringBuffer has all of the documents, the customer element is terminated, converted to a String and wrapped in a StringAspect. Based on existing mappings, if NetKernel is running and you installed the example module, you should get a list of customers
back in plain XML when you hit http://localhost:8080/customer. Remember the HTTP request is rewritten to an active:fetch-customers request, which gets rewritten to an execution of ffcpl:/scripts/defaultcustomers.bsh.
You usually want a nicely formatted list of data, so now you will convert the XML that comes back from active:fetch-customers into some nice HTML. NetKernel has plenty of tools to help you do this. XRL is a recursive template mechanism not unlike Cocoon and similar tools. To keep you from getting confused, the module is configured to map external requests for http://localhost:8080/xrlcustomers to a BeanShell that will do the XSLT conversion of the data that is returned from the logically named customer persistence
layer. Normally, you would use the same URL and content negotiation to decide whether to return XML or HTML. The module exports
ffcpl:/xrlcustomers.* and then configures this behavior with a rewrite rule:
<rewrite>
<rule>
<match>(ffcpl:/xrlcustomers.*)</match>
<to>active:mapper+operator@ffcpl:/links.xml+operand@$1</to>
</rule>
</rewrite>
This works because the sample module imports the XRL handling behavior:
<import>
<uri>urn:org:ten60:netkernel:ext:xrl</uri>
</import>
The XRL handler expects a file of links that customizes one or more rewrite rules. (It would get really old having to specify them all by hand!)
<links basepath="ffcpl:/xrlcustomers/">
<link>
<name>index</name>
<ext>/index.html</ext>
<int>active:xrl-html+template@ffcpl:/content/customers.html+content@xrl:customers</int>
<args>links</args>
</link>
<link>
<name>customers</name>
<int>active:beanshell+operator@ffcpl:/scripts/customers.bsh</int>
</link>
</links>
A complete XRL tutorial is beyond this article's scope, but what is happening is that a request for ffcpl:/xrlcustomers/index.html is going to be rewritten to invoke the templating of the ffcpl:/content/customers.html file with whatever comes back from issuing the xrl:customers link. This currently points to the execution of ffcpl:/scripts/customers.bsh. The HTML template looks like Listing 2: