Uiinfrastructure API Docs  
 

com.plumtree.uiinfrastructure.activityspace Namespace

Namespace hierarchy

Classes

Class Description
AActivitySpace AActivitySpaces contain the MVC setup for a set of Display Pages, as well as the Display Pages themselves. All objects should come to their parent AActivitySpace for access to other objects, such as IModels, IViews, and user objects like IPTSession and UserPreferences. Activity spaces setup and manage the interaction between the different MVC objects and the IDisplayPage. They initialize all of the objects, and can get and set data on the Models if necessary. Activity Spaces are not subject to the strict data/logic/presentation separation that MVC components are. This class provides helper implementations of the methods to get MVC Objects and manages them automatically (IModel, IView, IControl, IDisplayPage). Just register things and then call GetModel, etc... to access them. It also provides base implementations of some of the common AActivitySpace functionality.
AClearModel This model is designed to have all of it's data stored in a temporary data storage object. This object will be automatically deleted at the end of every HTTP Request and regenerated at the beginning of the next request. This is for browsing pages that have low-memory requirements. This means that data will only be stored during requests. Admin and Editor pages should probably not use this model scheme. All data should go on the temporary storage object, especially Query Results and large arrays. The design of the temporary data object is left to the implementor's discretion.
ASCache This handles the cache for developers so that it can't get into an inconsistent state. Note: ClearCache() should not be used. This is only for debug purposes.
ASConstants Constants used as arguments in the query string or in form POSTS.
ASManager  
ASURL This class creates an URL that points to MVC components. This adds the session user ID to the query string for usage tracking purposes (PTTracker).
ASURLContainer Stores an Activityspace URL. Should be used in model components when creating URLs. Can easily be converted to ASURL in the view layer.
HTTPHeaderConstants This has HTTP header constants.
Interpreter This class is deprecated; it exists only for backward compatibility so that prior code referencing this class will compile. This class is replaced by Interpreter and MVCController classes in the com.plumtree.uiinfrastructure.interpreter package.
LinkConstants This class contains constants for the ILink classes.
Redirect This object allows IControls to specify an AActivitySpace, IDisplayPage, or IControl to redirect to. Currently, only AActivitySpaces and IDisplayPages are implemented.
WebData This object wraps HTMLPages and binary data for output to the browser. There will be methods for setting HTTP Headers for the browser. This implementation of the IWebData interface is intended for use by the Interpreter.

Interfaces

Interface Description
IControl Controls process the events generated by users. The Interpreter takes the user events and fills out the fields in the control. The control is then executed and returns the next DisplayPage (usually the parent page, unless the control is a go to url control). Controls should encapsulate the business logic of the AActivitySpace. As an MVC component, Views are subject to the strict separation between data, logic, and presentation. Obviously, there should be a good way to refer to controls without having to manually type in a text string. There should be some sort of package identifier used to get these.
IDisplayPage Display Pages aggregate Views and put them into an HTMLPage. They are owned by Activity Spaces and represent a view into an MVC framework. Display Pages are allowed to get and set data on the Models, if necessary. Display Pages are viewed as an extension of Activity Spaces, and therefore are not subject to the strict data/logic/presentation separation that MVC components are.
IHTTPControl This interface should only be implemented by controls that need to perform special HTTP things, such as reading HTTP headers, getting/setting cookies, and file upload. These are special cases, and most controls should not use this. The gateway needs access to the raw request in order to get all the necessary information that is not normally passed from the interpreter to the AS. In particular, gateway needs access to the raw body and raw headers.
ILink This interface provides a common way to create an object that links to an AActivitySpace. It also provides methods to specify optional Page, Controls, and Query String arguments. To use this interface, first create an object that implements the interface, then call one of the SetSpace* methods to set what kind of link you want. Than add optional arguments (page, etc...)
ILinkElement  
ILoginControl This interface should only be implemented to provide login functionality for the portal. This is a special case.
IManagedObject This interface is used by the ASManager to return new instances of managed objects.
IModel Models encapsulate the data in the MVC framework. Views have access to the read only model interface and should only read data from it. Controls get and set data, and therefore use the base IModel interface. Models should encapsulate the data handling of the AActivitySpace. Temporary UI data that you want to store for each user should go here. As an MVC component, Models are subject to the strict separation between data, logic, and presentation. It is a requirement that Models not reference HTMLElements or HTMLConstructs. Models can return text Strings for display in HTML, but they are not allowed to use HTML themselves. It is also a requirement that Models not return server structures to Views. For instance, rather than returning an IPTQueryResult to a View, the model should provide accessor methods to it. Views can use server constants such as PT_PROPIDS.PT_PROPID_NAME. Obviously, there should be a good way to refer to models without having to manually type in a text string. There should be some sort of package identifier used to get these. When writing a model class, the Get methods (read-only methods) should be split out into an IMyModelRO interface, which MyModel then implements. MyModel would also include all of the Set methods (write methods) and any helper methods. There does not need to be an IMyModel interface for the Set methods, unless you are expecting someone to implement their own version of your model.
IModelRO Models encapsulate the data in the MVC framework. Views have access to the read only model interface and should only read data from it. Controls get and set data, and therefore use the base IModel interface. Models should encapsulate the data handling of the AActivitySpace. Temporary UI data that you want to store for each user should go here. As an MVC component, Models are subject to the strict separation between data, logic, and presentation. It is a requirement that Models not reference HTMLElements or HTMLConstructs. Models can return text Strings for display in HTML, but they are not allowed to use HTML themselves. It is also a requirement that Models not return server structures to Views. For instance, rather than returning an IPTQueryResult to a View, the model should provide accessor methods to it. Views can use server constants such as PT_PROPIDS.PT_PROPID_NAME. Obviously, there should be a good way to refer to models without having to manually type in a text string. There should be some sort of package identifier used to get these. When writing a model class, the Get methods (read-only methods) should be split out into an IMyModelRO interface, which MyModel then implements. MyModel would also include all of the Set methods (write methods) and any helper methods. There does not need to be an IMyModel interface for the Set methods, unless you are expecting someone to implement their own version of your model.
IMVCObject This interface provides a common method of finding the name of an MVC object.
IPageControl  
IValidator Interface for page control validators. Validators are objects for standardized Page Control validation and contain both server-side and client-side validation.
IView Views are responsible for generating HTML in the MVC framework. They query their model for data and build HTML from it. The links and forms in that HTML should be constructed so the Interpreter can use the controls to process events. Views should encapsulate the presentation of the AActivitySpace. As an MVC component, Views are subject to the strict separation between data, logic, and presentation. It is a requirement that Views not contain any server code other than constants (i.e. PT_PROPIDS.PT_PROPID_NAME). IPTQueryResults should not be used in Views, rather, Models should provide accesor methods for them. It is also a requirement that Views not depend on Models for HTML. Views can use helper classes (Strategies, delegation, etc...) to generate HTML, but Views should never expect a model to return an HTMLElement or HTMLConstruct to them. Models can return text Strings for display in HTMLElements. Obviously, there should be a good way to refer to views without having to manually type in a text string. There should be some sort of package identifier used to get these.
IWebData This object wraps HTMLPages and binary data for output to the browser. There will be methods for setting HTTP Headers for the browser. This interface is intended for use in IDisplayPages.