3. Presentation

3.1 Status regarding modularization

The presentation logic is not modularized very much. In this chapter, some suggestions about future directions the presentation "engine" could go are made.

The suggestions made in this chapter are quite a bit away from being a specification. This is so because the author is aware of the limited resources the project has. As soon as these suggestions are considered worth the effort to implement some of them, the chapter is improved with concrete specifications.

3.2 Current Situation

The presentation of Action Application content is currently done using a regular html page which includes the php script slice.php3. Pages presenting content need to have the permission to include programs; this is done by enabling the execute permission.

The slice.php3 script contains all the presentation logic in a monolithic script. It displays information as a tabular listing with one item in a row, or, in full text view, one item with its full text. When displaying data, the script uses information from the slice configuration to format the items. It also displays, when called with the appropriate parameters, a search form and search results.

This approach provides a very handy interface to the slice owner. Slice owners get a simple ASCII string which they need to place into their html page and everything is set to show their news.

On the other hand, the need to enable execution of programs from a server side include page creates security problems for site administrators. Current implementations of the apache web server do not allow to make security settings as specific as they would need to be to enable Action Applications functionality and also keep overall system security.

3.3 Future directions / options

Given further modularization is planned, the slice.php3 script should be broken up into pieces, each providing separated functionality. The pieces would go into a presentation module library. The actual slice.php3 script would than only call these modules to create the desired view. Such modules/functions would be created for

• displaying a search form
• getting a list of items according to given criteria (for example, the five latest items; the latest highlighted item; or items matching a complex search)
• displaying one item in compact view
• displaying one item in full text
• retrieving an item without displaying it (for example, for presentation on something different than a web site)
• caching information between module library function calls (for example, when displaying ten headlines of a slice, the slice record must be cached between calls to the display function)

In order to help resolve the security issues, a presentation page wrapper program would be created which is executed whenever a Action Applications presentation page is accessed on the web server. A special file extension (for example, .aa) would be introduced to identify Action Applications presentation pages. When the web server sees that a file with this extension is accessed, it would start the wrapper program which would then show the page and in turn call the slice.php3 script. This avoids the need of server side includes and thus the security issues.

3.4 Benefits of modularization

The benefits of further modularization are not so obvious, but there are some:

• Presentation of content could be easily modified to suit different needs on web pages. For example, a site might want to display headlines of the latest one or two items of a slice on the index page and have a news page displaying a different number of item headlines.
• Presentation can be easily extended to non www media. For example, the email subscription service or the cross server networking service could use the presentation modules. Development of any modules which access data would be easier.
• Developing the presentation wrapper would improve security a lot.
• Finally, maintainability of modularized code with well defined interfaces is much easier.