| Class |
Description |
|
AComponent
|
This is the abstract class for all page controls. A page control is a single input/output component on an web page. One example of a control is the datepicker. For each instance of the datepicker on a single page, you need an instance of an AComponent. Components of like controls are managed through a single component manger. So, on a single page you might have 3 datepickers (3 instances of AComponent) all managed by a single datepicker manager. If you were to have other types of controls on that same page, you would need an instance of the appropriate componetent manager for those controls. The Page manager aggregates all instances of component mangers and provides access to page specific information that might be relevant to controls (i.e. locale and timezone). In summary: Component - Might have many on a page (i.e. datepicker). Note: There is really no difference between a "component" and a "control." Component Manager - One per type of component on a page. Page Manager - Only one per page. Aggregates all the component managers. How is the component manager differnt from the page manager? Why have both? The component manager serves two funtions. First, it aggregates like components. Second, it handles the printing of page-level content (contrast with component-level content.) Consider the datepicker example again. If you have 2 datepickers on one page, there is data that needs to be outputted once (page-level) and data that needs to be outputted once for each datepicker (component-level). One special note about the page-controls framework... It assumes that the client will be using the HTTP Session for state management. Given this, the client needs to have implemented a good HTTP Session mangment strategy that will release old or unused objects. See the documentation on Activity Spaces for such a framework. |
|
AHTMLComponent
|
JF- This is the abstract class for all HTML Element page controls. |
|
AValidator
|
|
|
ComponentMgr
|
This class manages instances of like components that all appear on a single page. For more information on the page controls framework in general, please consult the documentation for AComponent. There is one important concept to understand when it comes to the ComponentMgr class: for page controls, there is script to be outputted that has "component scope" and script to be outputted that has "page scope." Component scope means that the data needs to be printed once per component. Page scope means that the data needs to be printed once per page, independent of the number of times a component of that type is written to the page. The component manager allows you to print data for either or both scopes through a series of methods. Components may be registered with the component manager and then obtained either using their unique instance ID or by way of an int index. The index is determined by the order in which you registered the components. |
|
HTMLComponentMgr
|
The default ComponentMgr for HTML Page Controls who don't need additional JavaScript to render. This class extends ComponentMgr and as of now doesn't do anything new. |
|
JSComponentMgr
|
This class is meant to manage JS components. Most of the work is done by the parent class. However, there are some things that are specific to the JS classes that are handled by the JS registry. For many JS components (like the date-picker), you will want to override this class. |
|
PageMgr
|
The page manager (PageMgr) class aggregates all of the comoponent managers for a given page. It also page-scope information such as locale and time zone. It has some convenience methods that act on all ComponenteMgrs registered with the PageMgr and all their Page Controls -- StoreAllUserInput and Validate. |
