ProviderEditTypes Interface

The ProviderEditTypes interface defines the edit types that can be returned from the Provider.getEditType() method. The edit type informs a client of a provider object what it can expect to be returned from the provider’s getEdit() method. The edit type can be EDIT_COMPLETE or EDIT_SUBSET.

• EDIT_SUBSET - Indicates that the edit page is not a complete document. This value is potentially returned from getEditType() to signify that the buffer returned is only a subset of a document. The edit type, if subset, means that the JSP edit container is used to wrap the content from the container. This is useful for providing a common look and feel for a set of common portal pages. That is, it allows the channel’s edit page to look and feel according to the container that it exists within although the same channel might appear in two different containers that have very different look and feel. In this case the form that wraps the edit content generated by the provider is drawn by the edit container.

• EDIT_COMPLETE - Indicates that the edit page is a complete document. This value is potentially returned from Provider.getEditType() to signify that the buffer returned is a complete document. The container of the provider uses this information to determine if it needs to wrap it’s edit page output to form a complete document. This is done with something called an edit container.

  Containers use edit containers to provide a container-specific look and feel to otherwise heterogeneous providers. It allows the channel’s edit page to look and feel according to the container that it exists within although the same channel might appear in two different containers that have very different look and feel.

See the Javadocs for more information on the methods in this interface.

PropertiesFilter Class

The PropertiesFilter abstract class, when extended, can describe a specific filter criteria. To implement a specific filter, one must minimally implement the getCondition() and match() methods in the PropertiesFilter abstract class.

• The getCondition() method must return the condition on which the PropertiesFilter should operate.

• The getValue() method must return the value that corresponds to the given condition.

• The isRequired() method can be implemented to specify whether you want this to be a required filter or not. A conditional property lookup involves one or more property filters. If a filter in the filter list is required, then it must match for the overall conditional lookup to succeed. If a filter is not required, then it can fail to match without causing the overall lookup to fail.

  A chain of non-required filters can be used to implement a progressively less-specific filter lookup, similar to the semantics of Java resource bundle lookup. For instance, an optional filter would be useful in a case where a locale lookup is followed by a date lookup. Given the filter {locale=en, locale=US, date=03/03/2003}, you can get it to successfully match a property with the qualifier {locale=en; date=03/03/2003} even though it does not exactly match the filter specification. This can be accomplished by setting the locale filter to be optional. The locale property type is deprecated.

• The match() method returns true if this filter object agrees with or matches the condition and value that are passed in, given the information that was used to create the object.

Out of the box, the Portal Server software includes filters based on locale and client. The locale and client filter extend the PropertiesFilter abstract class and includes an implementation of the getCondition() and match() methods in the PropertiesFilter class. See the Javadoc for more details.

TypedException

TypedException is a Public Application Programming Interface (API), which the users can implement to create a user defined exception class. This interface helps to generate context related error messages rather than generic error messages. The user exception that implements TypedException can be thrown from the JSP incase of any error and the desktopservlet can display the proper error template according to the exception type set in the user exception.

The exception types defined in the TypedException interface are:

• public static final String NON_EDITABLE_TYPE = "nonEditableChannel";

• public static final String UNKNOWN_CHANNEL_TYPE = "unknownChannel";

• public static final String NO_PRIVILEGE_TYPE = "noPrivilege";

• public static final String SESSION_TYPE = "session";

• public static final String UNKNOWN_TYPE = "unknown";

• public static final String SESSION_TIMED_OUT = "sessionTimedOut";

Provider Exceptions

The Desktop expects a provider to only throw ProviderException or a subclass of the ProviderException. For correct operation, a provider must only throw expected exception type. That is:

• Minor exceptions can be managed internally, for example, log a debug message.

• Serious exceptions can be rethrown as an expected exception type.

Exceptions from providers are logged in PortalServer-DataDir/portals/portal-ID/logs/portal-instance/portal.0.0.log file. Note that this file is created only if there is an error.

ProviderException Class

The ProviderException is a generic superclass for all provider related exceptions.

AsciiFormInputExpectedException Exception

The AsciiFormInputExpectedException will be thrown from Provider.processEdit() method when something other than ASCII only encoded form input is sent to it.

InvalidEditFormDataException Exception

The InvalidEditFormDataException is thrown from the Provider.processEdit() method when there is an error in the data input by the user. If thrown, the Desktop will send back the same Edit page, and will attach the exception’s message as a parameter to the URL. For example, if the exception is:

throw new InvalidEditFormDataException("Error Error");

the Desktop will redirect back to the same Edit page, adding the error message to the URL error parameter:

error=Error Error

The edit page wrapper then looks for the error parameter in the URL and if present, displays the message (or the value of the error parameter) at the top of the page in red.

UnknownEditTypeException Exception

The UnknownEditTypeException may be thrown from Provider.getEditType() method if an unknown or undefined edit type is encountered.