01: /* Copyright 2005 The JA-SIG Collaborative. All rights reserved.
02: * See license distributed with this file and
03: * available online at http://www.uportal.org/license.html
04: */
05:
06: package org.jasig.portal.channels.portlet;
07:
08: /**
09: * Marker interface for IChannels to communicate that they wish to be treated
10: * in the ways we treat JSR-168 portlets being rendered via IChannels. This
11: * includes being rendered when minimized, etc.
12: *
13: * uPortal infrastructure can check any given IChannel to see if it implements
14: * this interface to determine whether it should treat it specially or not.
15: *
16: * @since uPortal 2.5
17: */
18: public interface IPortletAdaptor {
19:
20: // this marker interface declares no methods.
21:
22: }
23:
24: /*
25: * TODO: better document exactly what special behavior is expected for
26: * channels implementing this interface.
27: *
28: * TODO: maybe this interface should extend IChannel. Do we expect anything
29: * other than an IChannel to want to use this marker?
30: */
31:
32: /*
33: * A marker interface is an appropriate solution to the problem of IChannels
34: * communicating that they wish to be treated as JSR-168 portlets because
35: * JSR-168-ness is a java coding time attribute of a particular IChannel
36: * implementation. A particular IChannel either wishes to be treated in these
37: * ways or it does not. Presumably all IChannels that choose to implement this
38: * interface indicating that they wish to be treated as JSR-168 portlets will
39: * in fact be IChannel implementations that are backed by JSR-168 portlets, but
40: * this is not a hard requirement. In theory any other IChannel wishing to have
41: * an opportunity to render content even when minimized (or take advantage of
42: * other ways in which portlets are handled specially) could implement this
43: * interface.
44: *
45: * There are several places in the code where we need to treat IChannels seeking
46: * to represent portlets differently than other portlets. There are alternative
47: * solutions to this problem that we could have adopted.
48: *
49: * This approach was selected in preference to checking for the default CPortletAdaptor
50: * directly, as that would have introduced a tight coupling to a particular
51: * channel implementation, would have made difficult replacing that default with
52: * an alternate implementation.
53: *
54: * This approach was selected in preference to checking against a portal.properties
55: * property declaring the class name of the portlet adaptor, as that approach
56: * seemed to make runtime configuration of what is better expressed as
57: * a compile-time communication of an IChannel implementation of what it expects.
58: *
59: * Being a portlet adaptor is more a property of a particular piece of IChannel code
60: * than it is a runtime configurable property of a uPortal.
61: */
|