Introduction

HTTP request parameters are organized to come in key-value pairs (e.g. name=Joe). Here's a typical look of URI, containing request parameters:

http://www.somesite.com/request/path?param1=value1&param2=value2&...&paramN=valueN

In this example, the request handler is instructed to assign value1 to key param1 and so on. This is sufficient for many of the cases, however, sometimes it can be convenient to have the paths to be formatted differently. A good example of such a feature would be better search engine awareness.

Unify allows the system administrator to choose a different style for links to File store items, by selecting a different resolver per site.

Built-in resolvers

Unify comes with two built-in resolvers which are available for immediate use.

Standard resolver

This is the "classic" resolver, which maps param1=value1&param2=value2&...&paramN=valueN style request into item and vice versa.

Search-friendly resolver

This resolver is designed to provide greater awareness to search engines and is able to map /store123/item234/version345/fileservice456 into item and vice versa.

Resolver API

If none of provided resolvers can satisfy your needs, feel free to roll your own. This chapter explains what you need to do in order to achieve that. The request-to-item resolver is an entity, responsible for conversion of HTTP parameters into a single item (vyre.publishing.file.RequestToItemResolver). Its counterpart, item-to-request resolver is doing the opposite job by providing working HTTP link to file item (vyre.publishing.file.ItemToRequestResolver).

Below is the source of vyre.publishing.file.RequestToItemResolver interface:

package vyre.publishing.file;
 
/**
 * This interface denotes a level of API which has to be supported in order to parse item (and other item-related
 * entities, such as collection, file service, etc.) from HTTP request parameters.
 *
 * @author Albert Guðmundsson
 * @author Mindaugas Žakšauskas
 * @since v4.4
 * @see vyre.publishing.file.ItemToRequestResolver the interface with the opposite function.
 */
public interface RequestToItemResolver {
    /**
     * Implementing method should parse HTTP request and return item id.
     *
     * @return item id coming from HTTP request.
     */
    public String getItemId();
 
    /**
     * Implementing method should parse HTTP request and return item version.
     *
     * @return item version coming from HTTP request.
     */
    public int getItemVersion();
 
    /**
     * Implementing method should parse HTTP request and return collection schema id.
     *
     * @return collection schema id coming from HTTP request.
     */
    public String getCollectionId();
 
    /**
     * Implementing method should parse HTTP request and return file name for filestore items.
     *
     * @return file name of the filestore item coming from HTTP request.
     */
    public String getFileName();
 
    /**
     * Implementing method should parse HTTP request and return file service id.
     *
     * @return file service id coming from HTTP request.
     */
    public String getFileServiceId();
 
    /**
     * Business logic method of any resolver: sets the values by parsing HTTP request/response parameters.
     */
    public void setValues();

For convenience of implementing this interface, one can extend vyre.publishing.file.AbstractRequestToItemResolver which provides access to javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse. Then, by overriding method void setAll(), set the desired values to itemId, itemVersion, collectionId and fileServiceId. All necessary getters are already defined in the abstract class.

Below is the source of vyre.publishing.file.ItemToRequestResolver interface:

package vyre.publishing.file;
 
/**
 * This interface denotes a level of API which has to be supported in order to generate HTTP request parameters when
 * item & file services parameters are given.
 *
 * @author Albert Guðmundsson
 * @author Mindaugas Žakšauskas
 * @since v4.4
 * @see vyre.publishing.file.RequestToItemResolver the interface with the opposite function.
 */
public interface ItemToRequestResolver {
    public String getActiveFilePath( vyre.content.items.Item item );
 
    public String getFilePath( vyre.content.items.Item item );
 
    public String getActiveFilePath( vyre.content.items.Item item, vyre.content.processing.services.Service service );
 
    public String getFilePath( vyre.content.items.Item item, vyre.content.processing.services.Service service );
 
    public String getActiveFilePath( vyre.content.items.Item item, vyre.content.processing.services.Service service, String filename );
 
    public String getFilePath( vyre.content.items.Item item, vyre.content.processing.services.Service service, String filename );
}

Unlike to its counterpart, this interface doesn't have an abstract implementing class so you have roll your own if necessary.

In addition to implementing the pair of resolvers, it is necessary to implement your version of vyre.publishing.file.RequestResolverFactory, by joining the two interfaces together and providing factory methods to instantiate these resolvers. The factory might want to provide singletone instances for the sake of speed and statelessness of resolver nature.

Here's the API for the factory itself:

package vyre.publishing.file;
 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
/**
 * Factory provides new instances of actual resolvers and an API for resolver selection. Each site has its own factory
 * associated.
 *
 * @author Mindaugas Žakšauskas
 * @since 4.4
 */
public interface RequestResolverFactory {
    /**
     * Should provide with the new instance of {@link RequestToItemResolver}.
     *
     * @param request HTTP servlet request.
     * @param response HTTP servlet response.
     * @return new instance of {@link RequestToItemResolver}.
     */
    public RequestToItemResolver requestToItemResolverInstance( HttpServletRequest request, HttpServletResponse response );
 
    /**
     * Should provide with the new instance of {@link ItemToRequestResolver}.
     *
     * @return new instance of {@link ItemToRequestResolver}.
     */
    public ItemToRequestResolver itemToRequestResolverInstance();
 
    /**
     * Unique string identifier for the resolver. Will be stored in the database as a property of the {@link
     * vyre.publishing.Site}.
     *
     * @return factory identificator.
     */
    public String getResolverFactoryId();
 
    /**
     * Localization key for resolver factory - shown in site selection screen, possibly others.
     *
     * @return localization key for this resolver factory.
     */
    public String getResolverL10nKey();
 
    /**
     * Whether the resolver is default. Unless you want to mess up with {@link RequestResolverRegistry}, your method
     * should return false as default resolver is already built in and there can be only one default resolver.
     * System will behave unexpectedly if more than one resolver is default; most likely runtime exceptions will be
     * thrown.
     *
     * @return whether the factory provides default resolver.
     */
    public boolean isDefault();
}

Finally, the last thing you need to do is to register your factory in vyre.publishing.file.RequestResolverRegistry by calling

...
   RequestResolverRegistry.getInstance().registerResolverFactory( yourFactoryInstance );
...

After this is done, you should be able to use your resolver in Site edit screen and use it immediately.

Item Request Resolvers

From VYRE

Contents

Introduction

Built-in resolvers

Standard resolver

Search-friendly resolver

Resolver API

Views

Personal tools

Navigation

goto

Search

Toolbox