This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementation
In beginning development, the first step was to determine the overall architecture, including the folder structure, component usage, and styles to use. The largest part of this was for
Victor to determine what component and application elements would be used for what part of the application. This would determine how modular the application would be, and who would develop what and in what order.
Component and Application Elements
ColdFusion MX brings a number of new possibilities to the design of this application. It had always been Project Omega's practice to develop applications that were as modular as possible. This allowed for easy changes in the future as needs changed and new ideas arose. One of the challenges was to determine where to use what types of modular components. Victor could now choose from Enterprise JavaBeans, regular JavaBeans, Cold-Fusion components (CFCs), custom tags, or included files. That doesn't even include non-J2EE (such as COM objects) and ColdFusion possibilities. But even before he determined what technology to use, he needed to determine how to break up the application.
Victor decided that he would have low-level components for accessing basic information, such as XML registries. Above that, he would use custom tags to perform tasks that should be modular but at the same time accessed SESSION or APPLICATION variables. In general, these custom tags wouldn't contain too much layout; anything that had more than a modicum of user interface included should be developed as an included file.
At this point, Victor's objective wasn't to decide exactly what components, custom tags, etc. the team would need to create, but rather to determine what types of information would need to be done using what types of elements. Here is what he concluded:
Components
User information component(s) will need to return information about a user but not set it to SESSION scope or otherwise interact with the application.
User PSML component(s) would be responsible for reading a user's PSML file and returning relevant information, as well as writing and saving any changes to the appropriate XML files.
Registry component(s) would be responsible for retrieving information stored in the PSML registries.
Custom Tags
Authentication. This will allow for "locking down" secure information.
Session storage. Custom tags will be needed to write user information to session. This will include the design information highlighted by Ernie as well as other information that the user will need to access.
Portlet generation. The actual generation of portlets would probably best be done using custom tags.
Included Files
Static page drawing. Any templates that will participate in drawing the page but not contain substantial dynamic information. This section would include headers/footers and style sheets, as Ernie suggested.
Dynamic page drawing. Other templates will need to be created in order to "draw" a page dynamically for the user. This can include laying out the numerous portlets on a page or drawing any dynamic navigation elements that may be included in this application.
Portlets
The portal application itself will allow a new component type, the port-let. This will be used for providing the add/edit/delete interfaces.
After determining all this, Victor had Rhonda send a memo to the development team outlining the details of what needed to be created and what the directory structure would be.
Application architecture for Sonic Systems portal
Memo
Date: June 3
To: Project Omega Development Team
From: Rhonda
Subject: Application architecture for Sonic Systems
portal
We're off! It's time to begin development on the Sonic portal project. You should all have a copy of the blueprint. This memo will define how things will be done and who should do them. If you have any questions about functionality, contact Victor; about design, contact Ernie. I can field any other questions, or even serve as intermediary for design and functionality programs—just let me know what you need.
The following directories and templates will be used for the portal application (where Y is the Web root directory):
/portal/
The root directory of the application. This will contain the Application.cfm and the index.cfm templates—the controller pages of this application.
/portal/components/
This directory will contain the components of the application.
/portal/css/
This directory will contain the style sheets of the portal. Default.css will be the default.
/portal/images/
This directory will contain all images—subdirectories can be created, if necessary.
/WEB-INF/portal/conf/
This protected directory will contain the database and XML registries.
/WEB-INF/portal/lib/
This protected directory will contain dynamic templates that are included, such as the log-in and the administrative menu template.
/WEB-INF/portal/portlets/
This protected directory will contain portlets—subdirectories can contain whole portlet applications.
/WEB-INF/portal/psml/
This protected directory will contain users' PSML files, in the appropriate subdirectory.
/WEB-INF/portal/style/
This protected directory will contain design information, such as includes, in the appropriate subdirectories.
/WEB-INF/portal/tags/
This protected directory will contain any custom tags for this application.
The following tasks will be done in the following order:
Create CF_PORTLET custom tag for rendering individual portlets, and registry.cfc to read PSML registry entries.
Create demo information for testing, including demo portlets, anon user PSML, and demo registry.
Create component to read user PSML files.
Create writer(s) to set user preferences to SESSION.
Create page-drawing mechanisms—the Controllers.
Attach into full application.
Create Administrator and single-sign-on portlets.
Create "real" portlet registry and user to test.
And so, development began...