High Level Design Notes
Below are some high level notes for CW.
- Within CW, from the MVC architecture perspective, views follow one of the following structures:
- A single JSP acts as both a controller and view (for example, CWForwardDlg.jsp).
- One JSP page acts as a controller (
Mgris in the name) and a second JSP page creates the view (CWEditAttributesMgr.jsp, CWEditAttributesDlg.jsp). - A single JSP page acts as the controller, which generates XML. The XML is formatted using a style sheet.
- Note, all requests are filtered through a common initialization/authentication mechanism.
- Reusable Components: (Note, standard tools may have some reusable components – such as the status tool – but in general, standard tools do not have reusable components in order to keep the design for tools simpler.)
- Overall: The views for Contenta Web were developed as reusable components. Views were made as independent as reasonably possible to allow them to be reusable.
- Parameters: All requests that a view supports and the parameters it needs are documented. Parameters may come from the session, URL, or preferences (stored in AppData and the registry). All views accept the following as parameters (see below for more information.):
- Request - support an
initrequest at minimum - IdPath – idpath
- Request - support an
- Initialization: Each view handles an
initrequest at minimum that uses only the command object and URL map from the session object and takes all other necessary parameters as URL parameters or from documented preferences (stored in AppData or the registry – see preferences section below). - Session Object: Intermediate information specific to a view is stored in the session object, but the session object should be kept reasonably small. A session object is stored for each user connected to the web server using Contenta Web and can be a huge performance hit if it is large. The CWSession wrapper class is used to access the session object.
- XSL parameters: In addition to the data to be formatted for display, an XSL style sheet may need additional parameters to help control the display of the page. These parameters are passed to the style sheet as parameters or in some cases as metadata within XML tags.
- XML Data Definition: Each view that uses XSL defines the XML data set it expects – including both data and metadata that need to be supplied.
- Processing within a view/page:
- Each JSP page creates a CWSession object and calls its
initCheckConnectionmethod passing the appropriate information. If an error is returned by theinitmethod, the JSP page should take no other action. - The view services the request - typically by executing the appropriate API calls.
- The view returns the HTML page to the user. This HTML can be generated in two ways:
- Using JSP exclusively.
- Using an XSLT style sheet and passing it the XML data to be displayed and any metadata needed to create the page.
- Note 1, in general, if the view is data driven, an XSL style sheet is used to format the data into HTML. If the view is form driven or static, just a JSP page (without the XSL) is used.
- Note 2, in working with JSP/XSL most of the processing is done in the JSP and the data and metadata needed to create the view are sent to the XSLT style sheet.
- In either case,
CWUserConfig::getURLshould be used to obtain the full URL for ANY URLs that are used in JSP/XSL page. Before invoking the XSLT engine, the XML URL map is obtained in the JSP page and sent as metadata to the XSLT style sheet. This allows for custom code to be used without effecting installed files.
- Each JSP page creates a CWSession object and calls its
- Other Notes
- HTML
HTML pages should be converted to JSP pages so they can dynamically generate link information for images, etc.
- XML Conventions
- Where possible all Element Names are in caps.
- The outer Element Name is <DATA>.
- Internal Elements have names that pertain to the data. (e.g., <CFGLIST>, <PROJLIST> and so on)
- HTML