Learn to be a pmdev vigilante in 21 days!

Recently, vroom created the pmdev team, for the purpose of improving the Monastery technically. The Monastery, it should be noted, is already remarkable as a highly functional free service; nevertheless, we'd all like it to be better yet.

And while a relatively small number of people are looking at the code, I think there's much room for contribution by monks at large. In the same way that pmdev people bring their code to vroom for consideration, it seems to me that the work of Monks at Large can be brought to the attention of pmdev folks. It hasn't been discussed, really, but you don't need a license to tinker with public bits of the site... there's no guarantee that anything will come of it, but it's at least more productive than kibitzing.

For instance, one of the areas I'd like to see improved is the quality of the markup on the site. To that end... and, really, without any expectation of seeing my work adopted in any direct way... I did some experimenting. I think that this is an area where productive work can come from all quarters.

In what follows, it may be that I'm belaboring the obvious; if so, I hope you'll pardon me. It is certain that I reiterate some things said in the past, in the way of summarizing matters. Newer monks may find this interesting, and perhaps older ones won't mind for their sake.

Cascading Style Sheets have been brought up many times before in connection with the Monastery, usually when someone takes an interest in themes. Give us the ability to upload our own stylesheet, or to link to an external stylesheet, and presto! The Monastery looks just the way we'd always wanted it to. To a certain extent, we could even change functionality that way... changing the way code was presented, for instance, or hiding certain sorts of text.

The problem is, the site's markup isn't presently well-arranged to support CSS. There's a lot of HTML strewn throughout a lot of code, and all the presentation details are mixed in. The structure of the documents isn't expressed in the code, so you'd have trouble distinguishing this from that in a lot of important cases. Making the code more CSS-worthy is a major task, complicated by the fact that we run into problems if we come to depend on CSS. Many monks, often with good reason, use older browsers with little or no CSS support.

Now what would be interesting would be to see what could be done about sprucing up the HTML from various page types, maintaining old browser support while making the pages XHTML-compliant, and adding sufficient information to allow for the effective use of stylesheets. If such a work were available, it seems not unlikely that pmdev folks would use it as a model when editing the HTML embedded in code.

Consider this also. In many ways, a site-specific XML markup would be great for PerlMonks. There's a lot of regularity in what's presented, and right now much of that regularity is expressed by HTML explicitly embedded in the code. It'd be great, instead, to regard things foremost in terms of structure. For instance, an unnaturally short SOPW section could look like this:


<nodes>
 <category class="Seekers">
  <node>
   <head>
    <title>
     need PERL regex to parse html?
    </title>
    <date>
     Oct 03, 2001
    </date>
    <time>
     22:54
    </time>
    <replies>
     2
    </replies>
    <author>
     Anonymous Monk
    </author>
   <head>
   <body>
    like the titlesays help its due tomorow! thank u in advance -fred
   </body>
  </node>
 </category>
</node>
[download]

Not only is this more legible and maintainable, but it'd be great for folks like jcwren, who would doubtless come up with new toys to crawl across the Monastery and do clever things with the contents. Every page could be a ticker. The problem is, no browser I know of will render this properly, despite whatever stylesheet you provide... much less having *every* browser render it.

One solution to this would be to transform the markup before it's sent to the browser. This could be done in code, or it could be done with a specialized tool like an XSLT stylesheet. The latter, I think, would be the better solution; it would open things up so that various people could easily contribute, since they'd simply be contributing markup, rather than code. And once a XSLT document was created to transform the code into the markup the Monastery presently uses, we have backwards compatibility... we haven't lost anybody, and it's all gravy from there. Then if someone's favorite obscure browser doesn't handle things correctly, let them come up with a solution.

Of course, there are some serious downsides to this approach. While the base markup has been simplified, the complexity has been pushed elsewhere... into the transformation process. Hopefully the more modular nature of doing this sort of thing would still make it an improvement, but it's not a free ticket. The other thing (which probably occured to most of you immediately), is that this sort of highly dynamic serving would put a serious load on the server. Though some such work is done already (transforming <code> tags into <pre><tt> tags, for instance), this would be much worse. Caching would help matters, but not make the problem go away entirely.

Ultimately, this might well be a fatal flaw. I don't know. But I do know it'd be neat to see an XSLT doc take a terse XML description of a PerlMonks page and turn it into the appropriate HTML to render that page just as it looks on PerlMonks. Just because you made it, of course, wouldn't mean anyone was obliged to use it... but who knows? And perhaps if you had another XSLT doc to transform the XML into something else...

Just some thoughts. You can bet that the coolest stuff renegade developers could cook up hasn't occured to me.

Comment on Learn to be a pmdev vigilante in 21 days! Select or Download Code

Replies are listed 'Best First'.

Re: Learn to be a pmdev vigilante in 21 days!
by pjf (Curate) on Oct 05, 2001 at 16:25 UTC

All the XML to HTML transformation was done server-side, which does incur a very serious performance hit. In the case of this particular product, pages consisted of many well-defined objects, and once these were rendered once for a particular user profile, those objects could be agressively cached. This meant that things could still run at reasonable speeds, despite the performance hit of the XML to HTML pipeline.

PerlMonks is blessed with a similar structure of well-defined objects. We have nodes and nodelets, most of which remain fairly static (with a few exceptions). Being able to agressively cache and assemble these objects, rather than doing a full transformation with XSLT, would no doubt make an XML backend much more possible without major hardware upgrades.

If the PerlMonks code does not already do so, I would strongly suggest thinking about caching strategies for both XML and rendered HTML code. This might even provide performance benefits even if we did stay with a pure HTML website.

What Petruchio is discussing is possible and is certainly worthwhile. Just make sure you don't burn a hole through your CPU in the process. :)

Cheers,
Paul

[reply]