Another Update

This post is more than 2 years old.

Blog 2.1 is now posted. Changes include:

  1. Authenticate method is now in blog CFC where it belongs.

  2. blog.ini file structure has changed. Before, there was a root section called "blog" with one value, name. This allowed you to say, the default blog is 'foo'. Now, we have a root section called default. If you do not specify a name when you call init, these values will be used. If you specify a name and do not specify one of the values, the default will be used. If you try to init("fred") and fred isn't an ini file section, you get an error.

Warning - This update changes the ini file structure. Be sure to carefully integrate the new changes.

  1. Remember Me function added to Add Comments.

  2. Logout link added (for when you are logged in, of course).

Coming Soon: Support for N blogs w/ one database.

Question: Should blog support non-db persistence? Ie, should I allow you to store your data in xml files instead of SQL Server?

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by PaulH posted on 7/9/2003 at 2:12 PM

there's already a cfXML based blog. it requires cffile, which is even more of a workaround than re-writing yours not to use createObject.

is your blog i18n ready?

Comment 2 by anonymous posted on 7/9/2003 at 2:16 PM

Yes, an XML based blog would be nice instead of requiring a DB. Of course I haven't yet looked at your code to know the implications of that, but I think that's a good feature.

Comment 3 by Scott Keene posted on 7/9/2003 at 6:13 PM

I think XML storage is a more "blog-like" way of doing it really. You relieve yourself of dependency on another resource (db server) and have more of a "living document" for your blog entry's "permalink". How about an either/or option? No need to toss out the old code! Really, the BEST way that I could even think of would be to render them to (X)HTML directly - a true "permalink" that requires no server to process other than the web server. You could even potentially have the admin upload the files to a non-CF site, pure HTML. Radio and others do things this way I believe, and it would be cool to see a CF implementation like this (though it would involve a lot of work).

That said, my own CF blogging software works with a database as well, so I am facing the same decisions. I have been thinking of abandoning mine and switching to yours already as a matter of fact, so make it store XML - I'll switch for certain! Heh.

Comment 4 by Raymond Camden posted on 7/9/2003 at 6:18 PM

Scott, if I do allow for XML, it will not be a conversion, it will be either-or.

Comment 5 by Scott Keene posted on 7/9/2003 at 6:25 PM

Yeah, I don't know why I said that, Ray - I should've assumed you weren't thinking of dumping the DB capabilities rather than the reverse! ;)

Comment 6 by Ben Forta posted on 7/9/2003 at 7:05 PM

XML as an option would make sense (make it an INI flag per blog), but not in lieu of a db. Some things (search, for starters) are just going to perform better in a database.

Comment 7 by Randy Drisgill posted on 7/9/2003 at 11:21 PM

Definately don't take away db support. It would be nice to have pure xml, and it does make since from a pure weBLOG standpoint... But DB is more powerful.

A little off topic, but I know in the last versions I still had to change a couple areas (email and page titles mostly) to be dynamic rather than hard coded to Camden info. Any plan to change this?

Comment 8 by Raymond Camden posted on 7/9/2003 at 11:26 PM

Let me repeat. I have NO plans of taking away DB support. The mod (IF I do it), will allow for DB or XML.

As for hard coded parts - I still look at this project as a blog CFC and my client. So, I assume people will tweak the client (layout, etc) and not just unzip and run. So I don't see a big need to make the client completely dynamic. Does that make sense?

Comment 9 by Raymond Camden posted on 7/9/2003 at 11:28 PM

Of course, if many people _want_ this, I can look into it. Certainly you will almost always have to edit the stuff in the right hand column, unless you play the exact same games and read the same books as I do. ;)

Comment 10 by Randy Drisgill posted on 7/9/2003 at 11:51 PM

Don't get me wrong, I love the fact that you released this code to make a simple blog... you are not required to make the code user friendly.

BUT, you recently made a bunch of things call from variables anyway... so when I grabbed the code I made variables out of these other things right away. For simplicity sake, here are the places that need changing (I think these are it)... there are only 5 lines total (which can pull from 3 variables in the blog.cfc ownerEmail, blogTitle, blogDescription):

addcomment.cfm (title)
editor.cfm (title)
layout.cfm (title, banner)
rss.cfm (email)

Comment 11 by Steve Ray posted on 7/10/2003 at 12:16 AM

Yes, please. I was thinking about finagling your app to do this myself, but I'd much rather you do it and save me the time. ;) I wrote one of these things myself and stored everything that way, but your's seems more full-featured, and I don't have the time to keep working on mine, so I think I'm switching.

Comment 12 by Jacob Reider posted on 7/10/2003 at 4:50 AM

a) Thanks for 2.1 ... looking good!
b) I agree with the XML option, but I think I'll stick with SQLserver.
c) Customization. I made many of the changes that Randy made .. so I guess that answers the question ... making these components more dynamic would be a good thing.
d) Feature request. Here goes .. I have two ideas for features .. but I don't want to dump all requests into Ray's lap .. so ... Nate suggested Sourceforge/CVS ... any interest in this? ... We could all work on separate features ... such as ... 1) RSS 2.0 .. I'd prefer RSS 2.0 or even 0.91 to RSS 1.0 .. not too hard .. I've already started some work on it ... 2) ( a bit of a taller order) .. ability to use layout/formatting templates from blogger or movabletype.

Comment 13 by Raymond Camden posted on 7/10/2003 at 5:20 AM

Jacob: c) Will do. d) SOurceforge... still not sure. I don't mind sharing my work, but I kinda want to control it still. ;) 1) If you can point me to a good URL on RSS 2.0, and tell me why it's better, I'll defintely consider it. 2) Can you point me to resources on them - and also - would it be a copyright violation?

Comment 14 by Jacob Reider posted on 7/10/2003 at 5:46 AM

yikes .. the RSS politics are tricky and complex ... a (very) short version:

0.91 was developed by Netscape and Dave Winer. Pure XML, and very easy to implement and subscribe to.

http://backend.userland.com...

1.0 was a separate endeavor that didn't involve the 0.91 folks at all. Lots of bad blood over this. RDF rather than pure XML.

2.0 is a superset of 0.91 and developed by Dave Winer

http://backend.userland.com...

A quick look at some of the issue:

http://backend.userland.com...

...

and of course there is the gestational echo/pie project:

http://www.intertwingly.net...

Intent is to develop what is not being called RSS 3.0 .. (proposed names include Echo and Pie .. as in "easy as pie") ...

But .. bottom line in my head is that RSS 2.0 makes valid RSS 0.91 feeds, so it's the safest method of providing an RSS feed today. All aggregators will read 0.91 or 2.0 feeds, but they won't all read 1.0.

Comment 15 by Raymond Camden posted on 7/10/2003 at 6:07 AM

Ok, I think I will do that. I'll keep the RSS 1.0 method and add another method so people can choose which one they want to use. Thanks for the URL.

Comment 16 by Jacob Reider posted on 7/10/2003 at 6:16 AM

yikes .. the RSS politics are tricky and complex ... a (very) short version:

0.91 was developed by Netscape and Dave Winer. Pure XML, and very easy to implement and subscribe to.

http://backend.userland.com...

1.0 was a separate endeavor that didn't involve the 0.91 folks at all. Lots of bad blood over this. RDF rather than pure XML.

2.0 is a superset of 0.91 and developed by Dave Winer

http://backend.userland.com...

A quick look at some of the issue:

http://backend.userland.com...

...

and of course there is the gestational echo/pie project:

http://www.intertwingly.net...

Intent is to develop what is not being called RSS 3.0 .. (proposed names include Echo and Pie .. as in "easy as pie") ...

But .. bottom line in my head is that RSS 2.0 makes valid RSS 0.91 feeds, so it's the safest method of providing an RSS feed today. All aggregators will read 0.91 or 2.0 feeds, but they won't all read 1.0.

Comment 17 by Nathan Dintenfass posted on 7/10/2003 at 9:06 PM

You don't lose control on SourceForge, necessarily. You still control who has access to commit things to CVS, and since you are already giving away the code there shouldn't be any issue. But, it would let you provide it via CVS, so you could have stable builds and development still going on more easily. It would also move discussion of features of the software off your blog (which may or may not be a good thing).

Comment 18 by Dave Powell posted on 9/23/2005 at 5:34 PM

hey ray...

...didn't see it posted already, but here's that cfxml blog, written by some folks in italy...

http://www.veggiani.it/avbl...

...not bad...was kinda dead for awhile, but it looks like Andrea Veggiani has picked it back up...

...and, last i checked, they were also on sourceforge...but that was a while back...