Discuss: Simple Content Management
by Chris Ross-Gill
- Editorial Comments
2 Not so useful
I’m skeptical of the value of a “roll-your-own” how-to article which deals with a proprietary (and not free) language… especially one which, as Oscar pointed out, doesn’t play nice with pre-existing standards. Then again, perhaps I’m just being totally ignorant and there’s millions of REBOL users out there… but I’ve never come across it before. Disappointing.
posted at 06:05 am on May 24, 2002 by Neil
3 REBOL?
Err… REBOL? Who uses this? Why not pick a language thats opensource like PHP, and that is on almost every good host in existance? I saw the title for this article and got excited. I’m article seems fine in and of itself. Just not very useful. Try http://www.evolt.org/user/eli/9186/index.html
The build a nice lil CMS in php w/MySql.
posted at 06:42 am on May 24, 2002 by James B
4 Why roll your own?
I’m not sure I understand the purpose of rolling my own CMS when there are over a dozen such systems available which are far more robust, functional, and free. These systems are often bult upon standards and widely-used open source technologies. I understand this is “Geek Week”, but smart geeks know there is no point in re-inventing the wheel.
Here’s a list of free CMSs:
http://clueful.com.au/cgi-bin/cmsdirectory/browse/Products:Free systems
posted at 06:58 am on May 24, 2002 by Jon W
5 A few points...
A couple of points in defence of REBOL…
REBOL is (mostly) free.
REBOL/Core (which is all this article requires) and REBOL/View are free downloads. REBOL/Command, REBOL/ViewPro and REBOL/IOS are commercial products.
REBOL does play nice with pre-existing standards.
It supports a large number of internet protocols and allows you to “roll your own”. It also supports XML.
And in defence of the article, the whole point is that this is a “CMS” which makes no assumptions about your server, instead generating flat pages on your development machine rather than dynamically on the server. That means PHP, ASP, Perl, JSP or whatever are not really alternatives – where as REBOL provides probably the easiest way of building an app to fulfill this task.
posted at 07:27 am on May 24, 2002 by Danny
6 XSLT very strong alternative
The first poster pointed out that we already have XML. I wanted to add to this in case anyone was wondering where to go from there. XSLT is similar to the per-element replacement rules the author is suggesting you do in REBOL. But XSLT is a W3 standard, free, and there are more than one companany and invididuals making processors for it.
XSLT is understood natively by both Internet Explorer 5 and Mozilla, so you can either deploy it on the browser side, client side (your development machine, making it spit out static HTML ready-to-be-hosted), or the server side. In fact, since its a standard, you can begin with a client side system, and then use exactly the same templates should you upgrade to a hosting service that offers an XSLT processor on the server (and there are now several pieces of software which do this, like Apache Cocoon and Apache AxKit).
XSLT is the only templating system that can live comfortably on all three points of the development/hosting/browsing pipeline.
Throw in a browser sniffer, and you can even deliver raw XML to Internet Explorer/Mozilla and have it format your page into HTML on your visitor’s CPU time instead of yours.
XSLT is as simple to learn as REBOL, and is more likely to be supported by advanced web site editors (maybe future versions of Dreamweaver and Frontpage, if they don’t already) than a proprietary system.
But if that’s not enough, a critical advantage of XSLT is that it comes with XPath. With XPath you can look anywhere in the source document from anywhere in the template using a simple, URL-ish addressing scheme. So, for example, say you want a button at the top of the page to turn on “Director’s Commentary” for your weblog/essay/novella, but you don’t want that button to appear if the document doesn’t contain any <commentary> tags in the XML. All you need to do is use XPath to see if there are any <commentary> tags up ahead before you actually include the button. Same can be applied to a dozen conditional menu links or UI elements, set both ahead of and after the body of the content iself.
In my practice, I’ve also found that XPath is invaluable for filling the TITLE atribute on links. When I get to an <a> element I just look ahead to the glossary section I’ve included in the XML source and suck that information out.
XPath also understands full URLS. If there’s an XHTML or XML resource on a web page elsewhere, you can suck in all or fragments of it while you’re building the template and include its contents in your own document’s XML tree. It’s as simple as:
Temperature in New York: <xsl:value-of select=“document(‘http://weather.boygenius.com/new_york-new_york.xml’)/city/temperatures/current_farenheit”>
That is ease and power I think anyone can respect.
There’s more about XSLT and XPath at http://www.w3.org/Style/XSL/
posted at 08:50 am on May 24, 2002 by Chris Wenham
7 ... and XSL FO
I’m a roll-your-own kinda guy.
For example, IIS has no analog to Apache’s mod_rewrite. So I’m trying to write one for IIS.
But I also read this article very skeptically.
I agree w/ the previous comments on XSLT’s superiority.
The previous poster suggests that you can “throw in a browser sniffer, and you can even deliver raw XML to Internet Explorer/Mozilla and have it format your page into HTML on your visitor’s CPU time instead of yours.”
A little further down the pike, I think it’s also important to keep in mind that HTML may be dated. One of the end goals of XSL FO (related to XSLT) is to specify rendering for XML elements (rather than having to adapt it into HTML).
The great benefit of doing this is that the semantic of the original XML markup is retained, instead of factoring down to a less-meaningful HTML, which has a generalized structure.
This change in the design of the web will allow a single resource to be both human and machine readable.
Of course, you can take my comments with a grain of salt, as poor as my page is right now. :(
posted at 11:40 am on May 24, 2002 by Jeremy
8 what
Or we can continue using any other data storage (sql etc) system + processing system which is oh so much more efficient and less time consuming.
For clientside processing this is also almost useless. It relies on built content files. That means we need to create scripts that build these special flat files. Why build straight to html, skipping the middle man, as it is the same amount of work? Data changes, build it once, done. Use xml if you have to.
I see no valid reason for the use of it – unless its an evil way to insure job security.
posted at 11:51 am on May 24, 2002 by leo
9 Re: what
Leo, It’s fine for you to continue using some efficient data storage mechanism today.
I don’t think anybody really argues about how you should store your data on_your_server. That’s up to you. It only really matters when you start exposing it as a resource on the web. As the semantic web emerges, existing databases, with their proprietary interfaces, will not be able to interop as well as an XML-based system. More and more, I am pondering the wisdom of relational databases. I suspect that in the near future, OO and XML DBMSs will become more accepted. SQL Server 2000 allows you to select XML based on a table. This is neat, but the current implementation is far from complete. It is possible that Microsoft has the foresight to add more complete XML support, but I am not so sure.posted at 01:57 pm on May 24, 2002 by Jeremy
10 I love XHTML
I know it’s a minor point, but don’t forget that another plus for XSLT is that the output is technically XHTML, not HTML, which is really just HTML with Great Table Manners. In my day-to-day work, that’s been the biggest benefit of my XML/XSLT projects – the fact that it has very little choice but to create the kind of well-formed HTML that makes developers drool. I hand-code all of my creative side projects, but there are many days when I go into mass production of web pages like a factory worker and I have no choice but to use Dreamweaver for the heavy lifting.
Yes, I’d like to convert the XML data into other formats in the future as well (print, wireless, fun fun!) and starting in on XSLT sets it up nicely, but today, right now, the XHTML output alone is worth it for me.
posted at 02:06 pm on May 24, 2002 by Al
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
1 Invent a new mark-up language?
Is it just me but does it seems rather wierd to suggest people to invent their own mark-up language (** === ## a.s.o) when we have a good fleksible mark-up language which is called XML?
I know this may only be an example and you could use whatever text string you want, but still i somehow makes my eyes hurt :)
Best Wishes
Oscar Eg Gensmann
posted at 04:29 am on May 24, 2002 by Oscar Eg Gensmann