July 29, 2005

via David Megginson | Aspect-Oriented Programming: Believe the hype?

Quoderat � Aspects

In a recent post David Megginson writes:

I’ve decided it’s time to figure out if aspect-oriented programming is worth, well, figuring out.

A group of us which includes Russ Miles, the resident AOP expert within x2x2x.org, have recently got together to work on several projects, mostly focused towards the development of LLUP. A spawn from one of the conversations has developed and we have found ourselves discussing Aspect-Oriented Programming in regards to Client-side Javascript as well as extensions of our existing AspectXML project. I was playing around with some code the other day which I pulled into a use-case and published to the group for comments. The feedback was good and as such I plan to spend a bit of time this weekend turning the sample into something more useable and then integrate it into the existing AspectXML code base.

For those who might have interest I have taken the original post and copied it into the extended portion of this post. Hopefully I will have more to add to it soon, but in the mean time maybe this might help get some creative juices flowing within the community. If you have any feedback I would very interested in hearing about it.

From my original post to the group:

A quick thought just came to mind of which I decided to quickly test, although I already knew it would work and work well.

The UseCase:Problem

In developing a corporate web presence ABCompany is in a constant state of flux in regards to the products the sell/distribute: They’re an online auction site.

While the auction categories generally tend to stay the same (of course they change often enough to be concerned with developing a fluid linking system for just the categories, not to mention products (brands, models, style, etc..)) the products are in a constant state of flux. Developing a common and logical system that builds from Wiki-styled linking, Wikis are a perfect example of why a constant state of flux can build links and break them all on the same page within a matter of seconds.

The one constant within an auction site (and a Wiki for that matter) is things are constant-ly changing. When a resource has sold and has a need to be archived or deleted from the system there needs to be a central way of updating all links that point to the old location. Redirects will work but redirects can quickly become out of control from many fronts, especially if a products moves through several stages within the auction life-cycle:

• Create entry for product,
• submit and acquire a link,
• the auction,
• the auction closes,
• the item is archived for further research to discover trends and buying habits,
• the item is deleted from the system

Keeping even one section in the system, the main directory, up to date with the various changes in location is bad enough. But in addition to the auction services offered you also have a thriving blogging community of members, each in whom will link to various items of interest, add them to a “wish-list” etc… and in doing so you suddenly find that the 404 is the most common line item in your log files as maintaing where a link points to its not something you see many people put too much concern into.

The UseCase:Solution

When a product enters the sytem it is given an ID that will never change and will always be accessible via a master product ID database. What suddenly and instantly becomes the obvious solution is to simply create a directory which is equal to the product ID in which a redirect is set to point the visitor to the current location of this product. However, as mentioned, redirects can get out of hand, and while this solution is less prone to recursive-redirect-hell you still need to implement a solution that will continually update all the links within the auction system to the current location of each product in question.

Simple sample solution: XML file that represents a page to be built (note:this shoud be an atom feed but for simplicity I will simply build a non-specific XML structure to quickly showcase the solution using an AspectXML/JavascriptAO type approach.

<?xml version="1.0" encoding="UTF-8"?>

<page style="user:blog.entry" xmlns:join="http:/ABCompany/Auctions:JoinPoint">
    <entry id="123456" title="This Rocks!">
        Check out this <join:product.CurrentLink id="123widget">new widget</join:product.CurrentLink> on the ABCompany Collectibles section of the auction site. Cool!
    </entry>
</page>

XSLTransformation File for processing:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:join="http:/ABCompany/Auctions:JoinPoint" exclude-result-prefixes="join">

    <xsl:variable name="joinPoints" select="document('./products/products.CurrentLink.xml')/products"/>

    <xsl:output method="xhtml" indent="yes" include-content-type="yes" media-type="text/html"/>
    <xsl:template match="/">
        <xsl:apply-templates/>
    </xsl:template>

    <xsl:template match="page[@style='user:blog.entry']">
        <xsl:apply-templates />
    </xsl:template>

    <xsl:template match="entry">
        <h1><xsl:value-of select="@title"/></h1>
        <xsl:apply-templates/>
    </xsl:template>

    <xsl:template match="text()">
        <xsl:apply-templates/>
    </xsl:template>

    <xsl:template match="join:product.CurrentLink">
        <xsl:apply-templates select="$joinPoints//product[@id = current()/@id]"/>
    </xsl:template>

    <xsl:template match="product">
        <a onclick="document.location = '{@currentLocation}'; return true;"><xsl:value-of select="."/></a>
    </xsl:template>

</xsl:stylesheet>

The XML file with the current location information should be obvious so I wont waste the space.

Please note that I chose to use the onclick event of the “a” tag instead of “href”. This was for a couple of reasons. First, when mixing namespaces within an HTML document its easy to slip up and cause an element which is normally within the html namespace to be bound to something else all together. When this happens, for various reasons the browser should not react to a click event by redirecting to the href value. Interesting to note that it seems the IE is the only browser that properly handles such a situation. None-the-less, to avoid the problem all together and to add to this solution the benefit of using a completely different javascript call (instead of document.location = ‘uri’;) becomes another benefit and and potential join point area to use a resource id to be located within another namespaced reference file to find the proper javascript function to use. Also note that the use of the before, around, and after values of AOP beome all that more valuable when you have a need to build out a joint point that does not have a 1 to 1 element equality. e.g. instead of an “a” element you may instead build out a form with several hidden elements, a text box, and submit button (just an example, not necessarily a good one).

Comments?