NetKernel 4 will not support Fragmentors

NetKernel 4 will not provide support for fragmentors.

The concept of fragmentors was introduced to support the fragmentation notation of URIs (the "#" sign that can be appended to a URI). Since fragmentor support was implemented as a post processing function we determined that this could be accomplished with a chained accessor call and so, in the interest of simplfication and unification, we will remove support for this concept in the up-coming NetKernel 4.0 product.

We strongly recommend that no new fragmentors be developed and when moving to NetKernel 4.0 that fragmentors be converted to accessors. For example, in the NetKernel 3.3 release we have converted the image fragmentors into accessor services.

The remainder of this page is left from previous releases and does not constitute a recommendation to use fragmentors.

Fragmentor - What and Why?

When an issued request includes a URI fragment identifier NetKernel first resolves the resource and then attempts to process the fragment with a Fragmentor component. Fragmentors are implemented in Java and are registered in a module.

Resolution and Invocation

Fragmentors are resolved within the context of the module initiating the request. First all fragmentors within this module are tested to see if they are suitable, then all imported modules are tested recursively. If no fragmentor is found them the resolution process steps up the request call stack. If no fragmentor is found an Unrecognised Fragment Identifier exception is raised.

Fragmentors may be invoked in one of the following ways:

• Explicitly from a FRAGMENT request. This is an explicit request to locate a fragmentor that takes a given representation to perform the fragment operation.
• Implicitly from a SOURCE request where the URI of the resource contains a fragment identifier (the part of the URI after the # delimiter)

Coding a fragmentor

The class org.ten60.netkernel.layer1.nkf.impl.INKFFragmentorImpl is provided as a superclass for fragmentor development.

The fragmentor subclass must implement a default no-argument constructor and call super() specifying a regular expression string for matching the request URI and the MIME type of the resource. The method void fragment(INKFConvenienceHelper context) throws Exception implements the fragment operation.

For example a null fragmentor would be:

protected void fragment(INKFConvenienceHelper context) throws Exception
{   String fragment = context.getThisRequest().getFragment();
    String fromURI = context.getThisRequest().getURIWithoutFragment();

    IURRepresentation from = context.source(fromURI);
    
    // do some work here
    
    INKFResponse response = context.createResponseFrom(from);
    response.setCreationCost(8);
    context.setResponse(response);
}

Issuing subrequests

While generally not necessary, fragmentors may issue sub-requests (for example, to perform some validation or to have access to some configuration data).

The context object may be used to source resources and issue sub-requests in exactly the same way as with Java Active Accessor development. Requests will be issued into the module address space of the module hosting the fragmentor.

Registering a fragmentor

A fragmentor is registered by placing configuration information in the host module's module.xml resource. An example from xml-ura is the XPointer fragmentor:

For each fragmentor a <fragmentor> element is placed with the <fragmentors> element (which is a direct child of the root element). <class> is the fully qualified Java class accessible within the current module.

Supplied Fragmentors

NetKernel ships with several fragmentors. Their source code is provided in the hosting modules.