|
Page Edited :
SLINGxSITE :
Resources
Resources has been edited by Mike Mueller (Feb 13, 2008). Content:ResourcesWhat is a ResourceTBD How to get a ResourceTo get at Resources, you need a ResourceResolver. This interface defines four kinds of methods to access resources:
Absolute Path MappingAs has been said, the absolute path mapping methods resolve(SlingHttpServletRequest) and resolve(String) apply some implementation specific path matching algorithm to find a Resource. The difference between the two methods is that the former may take more properties of the SlingHttpServletRequest into account when resolving the Resoure, while the latter just has an absolute path to work on. The general algorithm of the two methods is as follows:
The virtual path mapping may be used to create shortcut URLs for otherwise long and complicated URLs. An example of such an URL might be the main administrative page of a CMS system. So, administrators may access the root of the web application and directed to the main administrative page. The path mapping functionality may be used to hide internal resource organization from the request URL space. For example to better control the structure of your repository, you might decide to store all accessible data inside a /content subtree. To hide this fact from the users, a mapping may be defined to prefix all incoming paths with /content to get at the actual Resource. The map(String) applies the path mapping algorithm in the reverse order. That is, first the path mappings are are reversed and then any virtual mappings are checked. So, a path /content/sample might be mapped /sample to revers the /content prefixing. Or the main administrative page - say /system/admin/main.html - may be mapped to the virtual URL /. Relative Path ResolutionSometimes it is required to resolve relative paths to Resources. An example of such a use case is Script and Servlet resolution which starts with a relative path consisting of the Resource type, optional selectors and the request extension or method name. By scanning a search path for these relative paths a system provided Resource may be overwritten with some user defined implementation. Consider for example, the system would provide a Servlet to render Resources of type nt:file. This Servlet would be registered under the path /libs/nt/file/html. For a certain web application, this default HTML rendering might not be appropriate, so a Script is created as /apps/nt/file/html.jsp with a customized HTML rendering. By defining the search path to be [ /apps, /libs ] the Servlet resolver would call the ResourceResolver.getResource(String) method with the relative path nt/file/html and be provided with the first matching resource – /apps/nt/file/html.jsp in this example. Of course the search path is not used for absolute path arguments. Querying ResourcesFor convenience the ResourceResolver provides two Resource querying methods findResources and queryResources both methods take as arguments a JCR query string and a query language name. These parameters match the parameter definition of the QueryManager.createQuery(String statement, String language) method of the JCR API. The return value of these two methods differ in the use case:
These methods are convenience methods to more easily post queries to the repository and to handle results in very straight forward way using only standard Java functionality. _Please note, that Resource querying is currently only supported for repository based Resources. These query methods are not reflected in the ResourceProvider interface used to inject non-repository Resources into the Resource tree. Providing ResourcesThe virtual Resource tree to which the the Resource accessor methods resolve and getResource provide access is implemented by a collection of registered ResourceProvider instances. The main Resource provider is of course the repository based JcrResourceProvider which supports Node and Property based resources. This Resource provider is always available in Sling. Further Resource providers may or may not exist. Each Resource provider is registered as an OSGi service with a required service registration property provider.roots. This is a multi-value String property listing the absolute paths Resource tree entries serving as roots to provided subtrees. For example, if a Resource provider is registered with the service registration property provider.roots set to /some/root, all paths starting with /some/root are first looked up in the given Resource Provider. When looking up a Resource in the registered Resource providers, the ResourceResolver applies a longest prefix matching algorithm to find the best match. For example consider three Resource provider registered as follows:
When accessing a Resource with path /some/path/resource the Resource provider R2 is first asked. If that cannot provide the resource, Resource provider R1 is asked and finally the JCR Resource provider is asked. The first Resource provider having a Resource with the requested path will be used. JCR-based ResourcesJCR-based Resources are provided with the default JcrResourceProvider. This Resource provider is always available and is always asked last. That is Resources provided by other Resource providers may never be overruled by repository based Resources. Bundle-based ResourcesResources may by provided by OSGi bundles. Providing bundles have a Bundle manifest header Sling-Bundle-Resources containing a list absolute path prefixes provided by the bundle. The list entries are separated by comma or whitespace (SP, TAB, VTAB, CR, LF). The BundleResourceProvider supporting bundle-based Resources provides directories as Resources of type nt:folder and files as Resources of type nt:file. This matches the default primary node types intended to be used for directories and files in JCR repositories. Servlet ResourcesServlet Resources are registered by the Servlet Resolver bundle for Servlets registered as OSGi services. See Servlet Resolution for information on how Servlet Resources are provided. Filter ResourcesTBD |
Unsubscribe or edit your notifications preferences
