Forum OpenACS Q&A: Response to Utility of XSLT?

Collapse
Posted by Bryan Che on
If your question is really about the complexity of the ACS presentation/content system, then the issue goes deeper than merely the use of XML/XSLT.

As I see it, there are two dramatic differences in ACS 4.6's presentation layer from pervious versions of the ACS and OpenACS:

  • A design/architecture change from a system that generated, for each request, a corresponding Web page to a system that generates pre-instantiated UI-components that process page request information.
  • A change in implementation technology from ADP/Tcl (or ADP/AJP) to XSLT/XML. Note, though, that this change in implementation technology is driven in large part by the design and architecture changes.

I would suspect that a great deal of the complexity you find in the ACS 4.6 presentation layer stems more directly from the design change than the use of XML/XSLT.

In previous versions of the ACS, a request would go to a certain page that processed that request. The page would generate all the HTML for the request based upon some logic and db queries and then return the output.

In ACS 4.6, the architecture changed to resemble that of a GUI toolkit like Swing or MFC (ACS 4.6 was designed with the Model/View/Controller (MVC) architecture in mind). I haven't programmed in Swing before, but I have done a fair amount of work with MFC. In the GUI toolkit paradigm, I would write GUI components which would respond to various events. For example, consider a simple Windows dialog box. When building a dialog box in MFC, I would create a new dialog box which subclassed the CDialogBox class (or whatever it's called). Then, I would add event handlers like an OnOK() method, which would do the appropriate thing when the user clicked on the "OK" button.

Bebop, ACS 4.6's presentation components, works in a similar manner. If you are writing a Web page with a form, you subclass the bebop form component and add event handlers for the appropriate events, like the user hitting the "submit" button. Then, you add the new form object to your page. This page will be instantiated on server startup, and every request to that page will be handled by the one, already-instantiated instance of that page.

Programming the UI for ACS 4.6 Applications requires a fundamental change in approach to how one thinks about building Web UI's. Before, we could essentially treat each Web page request as a single program that would run in isolation from other page requests. With ACS 4.6, now the Web server is a system, and page requests are no longer so isolated. But, doing things this way buys several advantages, including increased code-reuse, easier maintainability in larger applications and Web sites, and flexibility in modifying the site.

The reason I've gone to great lengths to describe these design differences is because I personally found that this is from where the biggest confusion regarding ACS 4.6's presentation layer stemmed. Once I saw that using Bebop was like programming with a traditional GUI toolkit, though, things seemed much less complicated than before. I apologize if this distinction was already clear to you.

Now, regarding XSLT/XML: It's certainly possible to write a presentation layer similar to the old, ADP/Tcl templating system with XML/XSLT. Indeed, XSLT is a turing-complete language, so you could write XML pages that resembled ADP pages and XSLT code like Tcl code. So, XSLT is not necessarily more complex than what we used before--it's just new and different. But, when you combine XSLT/XML with the design/architecture of ACS 4.6's presentation system, then you can do some powerful things.

Because you are using the same UI components for various pages, and each page is instantiated just once, you can truly separate the way you present your Web page from the way you constructed the Web page. For example, say that you are building a page that lists bboard threads. Say that you want to switch between a threaded bboard view and a non-threaded bboard view. In either case, the threads that you list are the same, but the presentation of those threads is different. So, you could write a page that generated XML listing all the threads to display. Then, you could write two different XSL stylesheets: one for doing threaded displays, and one for doing normal displays. Changing the way the bboard threads are displayed is just a matter of swapping stylesheets--no coding changes necessary when generating the XML. This is not something you could have readily done with the old ADP/Tcl templating system.

Now, extending this example just a bit, a Web site can drop in any number of XSLT stylesheets to change the way certain content is displayed or to change the overall look and feel of a site without having to modify any of the application logic that generated the content to be presented.

Because you did not like the documents I listed and your question "is essentially a direct response to the complexity of ACS Java's content system," I have attempted to explain the benefits and design rationale behind ACS 4.6's presentation layer. This post is getting long and is not really on-topic for an OpenACS forum, though. If you want to get more feedback on ACS 4.6-specific questions, I suggest you post at http://developer.arsdigita.com/acs-java/bboard/forum?forum_id=26112 instead. I don't want to turn this thread into a discussion of ACS 4.6 versus other versions of ACS or OpenACS. But, since you asked about ACS Java, I have attempted to answer your question as well as I can. I hope this helps...