Related link: http://www.aspectxml.org
[UPDATE: I am currently working on the follow-up post, the second in a planned 4-5 post series. I have also been pointed at and have since got in contact with the TIBET folks about gaining early access to the bits, which apparently are in the final testing phase for release in the next 2-4 weeks. They are looking at finding a way to give me access and plan to get back to me ASAP. I would REALLY like to include the work from this project as part of this series, and if I can gain access to these bits before the end of the business day, I will hold things off for a day such that I can play around with TIBET and see if it is in a state in which brings benefit to this series.
At the end of the business day (about 7 hours from now where I am located, Mountain Standard Time, USA) I will either post the next entry of this series, or an update stating that I have gained access to the bits and will instead post it tomorrow, hopefully with inclusion of the TIBET bits to whet your appetite.]
[UPDATE: [2005.09.01 12:13pm MST, USA] As you may have already noticed, the second part of this series was posted yesterday. I am currently working on the explanation of how everything works, but for those of you familiar with XSLT, the code is in place and should, for the most part, be pretty self explanatory. Expect an updated post with full explanations in the next hour to hour and a half.]
Whether we immediatelly realize it, our company websites, corporate and personal blogs, community and personal websites, discussion forums, listservers, etc… all contain common elements that appear on a regular basis. And yet in most cases instead of taking the time to, in essence, externalize these assets such that when simple things change such as:
- an individuals contact information:
– their telephone
– home address
We instead choose to update these, in many cases, by hand. Yet the need to make changes to each instance of these assets throughout the entire site is simply unneccesary and furthermore can easily be automated and made part of the standard build process.
Enter Assets, Atom Feeds, and AspectXML.
In many ways, if we were to catalog the items that tend to be fairly common within our web domains, along with anything that may be related (e.g. photographs, hyperlinks to various related places on the web) and then store these items in separate Atom data feeds with an entry for each related item, published, and made easily accessible, we could make the effort necessary to maintain the content of a web site mere childs play.
Scenario 1: A product image changes: Update the data feed, process the site using AspectXML and the predefined weaving templates, and anywhere within the site this image is used will automatically be updated to point to the proper image (as well as the proper hyperlink if that has changed as well)
Scenario 2: What about hyperlinks: The 404 error page is something I know we have all come to love and accept as part of our web-based lives. But do you think that if it suddenly just disappeared, we would miss it? While I have no doubt there are a sentimental few who probably would, I would tend to believe the majority of us would eventually forget what 404 even stood for, becoming more folk lore that is told around camp fires to scare children into minding the “ways of the web” or face “the dreaded 404!”
…or maybe not (the scare children bit… not the site-wide hyperlink update for each instance of an asset ;)
Scenario 3: Another area of value comes when a link on a page may have more than one hyperlink, image, or meta information associated with it that can not be crammed together each and every time the asset appears on the site. By containing this asset within an Atom data feed and then using an entry for each related item, a simple dropdown menu can be shown when the user clicks the assets link to then expose all of the possible places this asset links to, all or at least some related photos, and any other information that might be of interest.
When you really stop to think how often we use and reuse the same assets on a website, having a system that enables us to keep track of these assets, where they are located, and then keeping each and every one of them up to date with all of the latest related information is something that could very easily become the most important part of our build process each and every time we rebuild our web sites.
With that, I will leave you to ponder the above, ask any questions, protest my beliefs that this really can, will, and actually does work and work well, or flat out call me a lieing thief who stole the idea from your notebook while you werent looking (you really should manage your assets a lot better you know… Hey, maybe this tutorial series might help! ;)
I am currently planning part 2 of this series for the same time next week. If that changes I will make a post a day ahead to notify you of when it will be posted instead.
NOTE: This post is the first of what I plan as a 4-5 post series covering the basic concepts, the code, the real world implementation and maintenance, and the impact implementing this system can have on small, medium, and large websites alike. Your questions, comments, and/or concerns are always welcome.
So what do you think? Can AspectXML(an AOP-based project developed by Russ Miles and myself) and Atom feeds that contain the latest information related to commonly used site assets help in bringing sanity to content management on your web site(s) or am I completely off my rocker? (for this, not other reasons… While your other reasons may be valid, thats just flat out mean bringing them out in a public forum like this… have you no shame! ;)