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. |