Archive for January, 2003

Go with the (control) Flow

Thursday, January 30th, 2003

(via cocoon-users and BeBlogging)

Whoever invented the flow, whoever implemented it here, and had anything to do with it and brought it to Cocoon is a FUCKING GENIOUS.

I shall erect an altar in my fireplace and burn incense to his holiness every single day, preaching for my soul, to be, at one day, of comparable intelligence with his…

Pier

PS Can you tell that I started using it? And that it did beat the crap out of me? Now I won’t be able to design any web application without it! And that’s the _beautiful_ part of it! :-)

Hmm…

Friday, January 24th, 2003

Uh… I don’t know whether to laugh, cry, or stop reading. Curious.

Trackback Enabled

Thursday, January 23rd, 2003

Not that anyone cares, but perhaps the info will flow better if it’s turned on. All posts will have a trackback link from now on.

Cocoon.apache.org Goes Live

Wednesday, January 22nd, 2003

That’s right.. Cocoon was approved as a top-level Apache project! The vhost is live. Congratulations guys. I see big things in the next year for Cocoon.

As you may or may not know, I’ve been toying around with getting MT and Cocoon running in parallel. Unfortunately, my server with MT isn’t running Cocoon, and my server with Cocoon doesn’t have MT running on it. I can’t get Cocoon on the MT server, and I really don’t feel like getting MT installed again, because it was such a pain. What to do.. *sigh*…

Busy busy busy

Monday, January 20th, 2003

Lack of content… been busy with school. I have a crazy schedule. At least I have the day off to get some homework done.

Things coming soon: Cocoon serving up MovableType’s content! Hooray.

Brainwaves in Synch

Thursday, January 16th, 2003

Mark does a useragent-based mod_rewrite to flip out client-specific CSS, which was what I was going to suggest he do, except using Cocoon’s BrowserSelector.

I’m not sure what it is about it, but exploiting bugs in browser’s CSS handling just doesn’t sit right with me. Besides, it’s just a roundabout way of browser sniffing :)

I guess I’d rather have lots of easy to read CSS instead of one big ugly centralized mess.

Moving Towards Interweb Nirvana

Wednesday, January 15th, 2003

Well it seems that I caused some sort of a stir with yesterday’s post about Mark’s fiasco. Don’t get me wrong; I love reading Mark, and my comments weren’t meant in a mean fashion.

What I was trying to get at, was that it seems to me that Mark needs a little bit more leeway with his online publishing. He seemed happy using XHTML 1.1, and then he toyed with the idea of having to migrate to XHTML 2.0, and was not happy.

Yesterday, I proposed mark use a “presentation layer”. This is just a fancy way of saying that he needs a better separation of his content and his layout. Sure, he uses XHTML + CSS + MT with a database backend, but apparently that’s not enough.

Mark needs the ability to store his data however he wants, and then spit out HTML, XML, or whatever his heart (or his reader’s hearts) desire. This is where Cocoon comes in, and this is where I plan on getting some work done with connecting Cocoon and MT together in a useful fashion.

One of the problems with how MT works is that it stores everything in the database, and then exports it to whatever format using the templates.

  • Editing templates in a textarea sucks
  • Where are the XML templates?
  • And most importantly,

  • Why doesn’t MT’s export do so as XML?

I am working on a Python script to convert MT’s loosely-structured export output to well-formed XML. This will be useful when I want to pull all of the entries into Cocoon.

Another option is to manually edit the MT templates to output XML, and then serve them up using Cocoon.

Why Cocoon?

  • I can use some sort of XML DTD that I know won’t change very much (DocBook, Apache Document v1.1).
  • I can output to any number of formats, and I can very easily serve up a “lite” page for older browsers or users who so desire.
  • I’m not screwed when the W3C releases another XHTML 2.0 spec.
  • I know my data won’t be changing whenever the W3C changes their mind about how data should be presented as (X)HTML.

So there you have it. Think about it. It looks like MT is getting something that looks like you can use Wikiesque commands, but then when I saw the Perl code that handled it, I ran away screaming.

Stay tuned.

See Mark, See W3C. Bitch Mark, Bitch!

Wednesday, January 15th, 2003

Poor Mark. The heydays are over, I tell you. What that boy needs is a presentation layer so he can mark his content in whatever format he wants. That way, if users want XHTML 1.1, they can have it, or they can get their daily Mark in HTML 4.01 Transition if they so desire.

It’s too bad he’s redesigning, it’s too bad he caved, and it’s too bad he’s bailing out and resorting to HTML4.

Sigh. I was just starting to warm up to his design, too.

Speaking of all this, my next goal is to link MoveableType with Cocoon. My plan is to have MT handle all of the content generation, and I’m going to set Cocoon right in front of all the XML archives I’m going to have. And I promise not to bitch when the W3C changes the specs on me :)

XHTML 2, The W3C, and Despair

Tuesday, January 14th, 2003

I’m going to keep this short and sweet. Mark and Zeldman, two people who don’t read this blog, have been complaining about the W3C and the embryonic XHTML 2.0 spec.

I’ve gone through the anger that Mark has regarding web standards, and I promptly gave up being angry at the W3C.

The W3C’s problem is that although they are one of the most important organizations on the Net, they refuse to let things “percolate.” While we’re looking at the XHTML 2.0 spec, we must realize that there are still millions of pages that are using HTML 4 Transitional because of incomplete implementations in all the browsers.

The W3C is asking us (developers) to move forward, while we’re still asking our users (and our browsers) to take valid XHTML 1.1. And in two years we’ll see an XHTML 3.0 spec, just as we’re starting to “plan for the future” by migrating our XHTML 1.1 pages to 2.0. Our users will be at least two steps behind the W3C.

It never ends.

What we as developers need from the W3C is a guarantee that the XHTML 2 spec will remain frozen for at least five seven years before they start springing new things on us.

After all, just how far can HTML go? How far does it need to go? In the end, it’s all just XML+ CSS.

Dive Into Leisure Time

Tuesday, January 14th, 2003

Sounds like Mark needs a break from the Interweb. Go for a bike ride, take a vacation, read a Hunter S. Thompson book… anything to to get your mind off HTML and web standards for a while. You’ll be grateful for doing so. Perhaps he’ll go back to XHTML 1.x

I’ve learned to ignore any spec from the W3C newer than 3 years, because even then, they won’t matter for another 2. It is heart breaking when you try religiously to practice what you preach, and live for the Church of the W3C. Did it, not going back. XHTML 1.x is good enough for now, and it will be all we’ll need for quite some time.