hoodwink.d enhanced


Son of WebPage #

by why in inspect

Okay, once again, the idea here is to make HTML easily expressible for beginnies during a tutorial. If we can show that Ruby can be used to assemble a blog template pretty nicely, then someone might go, “Okay, I’m doing this!”

Here’s the latest webpage.rb. And here’s RedHanded sort-of-translated to webpage-test.rb.


  div.entry do
    h2.entryTitle 'Son of WebPage'
    div.entrySection %{by "why(Visit why's homepage)":http://whytheluckystiff.net/}
    div.entryContent '_Okay_, once again, the idea here is ...'

Main changes:

  • Give elements a class (or classes) by attaching a method: div.button.red translates to <div class="button red">.
  • Give elements an ID by adding a bang to that method: div.page! translates to <div id="page">.
  • Got rid of link_to, using normal a.
  • Divs can now take a string containing Textile.

I wasn’t gonna do the bang but it looks cool. The method attachment trick is done in CssProxy.

said on 04 Jan 2006 at 14:30

It’s very cool, but I’m not sure I understand why you’d want to do it. You still have to know HTML , but then you also have to learn the special Ruby syntax for it as well.

ERB still seems much clearer to me. Perhaps that’s because I’m used to PHP and other templating languages, though.

said on 04 Jan 2006 at 15:59

Ennh. Well, maybe there is some value-add waiting in the wings here once we get HTML shoehorned into the Ruby syntax neatly. Don’t really know until we try.

Oh! Here is one: add the ability to define “custom” elements, which expand into combinations of standard HTML elements. Like, HTML macros sort of.

said on 04 Jan 2006 at 16:03

Well, also, then we give the nooobies some convenient standard “meta-elements” to start with. Obviously they will not be building their own right away.

said on 04 Jan 2006 at 16:04

I hate to be the downpour on the procession, but what advantage does this really have over erb? There’s something to be said for SOC , and erb kind of runs roughshod over that. Reversing the relationship, and putting the HTML in the Ruby rather than vice versa doesn’t improve matters, does it?

said on 04 Jan 2006 at 16:28

I don’t really know. Just fooling around with it, I’m really diggin it over the tag soup. Plus we can make it ensure XHTML compliance. I mean imagine letting the interpreter detect that for you.

I understand the reluctance, since it’s kind of dumbing down HTML and that’s never worked (Dreamweaver, GoLive!, etc.) So I’m prepared to go bust on this.

However, in playing with this, it feels competitive to erb and it’s much, much preferrable to Smarty, HTML ::Mason, stuff where you have two syntaxes going on which aren’t even the language you’re coding in.

said on 04 Jan 2006 at 16:34

meh, it’s just cool

said on 04 Jan 2006 at 17:14

Hey, just out of curiosity, have you seen Watir? http://wtr.rubyforge.org. It’s a way to poke at stuff on web pages, and your thingie here is eerily evocative of Watir.

said on 04 Jan 2006 at 19:35

Superb! somehow, this appeals to the Nuby in me..

said on 04 Jan 2006 at 20:36

Keep up the good work. Sometimes the payoff isn’t immediately obvious on stuff like this, but you never know what experimentation might lead to.

I like it.

said on 04 Jan 2006 at 23:38

I did something similar a few months ago (just spent 3 hours or so on it). It was fun, if not really useful.

Here’s the page.

Your method attachment idea is nice.

said on 05 Jan 2006 at 02:42

Can we have entry_section instead of the camelCased one?


said on 05 Jan 2006 at 02:58

average_joe: I guess it is up to you, just replace entrySection with your prefered class name.

But I think it’s a confusing use of methods – especially if this is aimed att newbies (like me).

said on 05 Jan 2006 at 03:03

Interesting, I especially like the use of textile ;-)

said on 05 Jan 2006 at 05:10

I’ve run across this one: webgen.rubyforge.org

said on 05 Jan 2006 at 09:48

Durante: see, yes!

average_joe: Yes, either.

jim: Wild. That Qt app that goes with it.

Libraries. They’re buried all over the hill.

said on 05 Jan 2006 at 11:56

I’ve been reading “The Art of Unix Programming” recently. This almost runs counter to Generation: Pushing the Specification Level Upwards because something declarative is being turned into code. I see that we get Ruby to check the structure “for free”, but we’d get that from some kinds of data structure, possibly: Is it possible to declare YAML types that can’t contain certain types (to respect the nesting restrictions on HTML , but still have readability) for example?

There are interesting things going on at this “data generates code”/”code generates data” boundary, similar to the declarative/imperative boundary in languages….

said on 05 Jan 2006 at 15:00

hgs: You’re thinking YAML schemas, basically?

said on 06 Jan 2006 at 12:14

I have once or twice embarked on making an SVG (or otherwise) charting library, I think this approach could be really useful for creating the markup.

said on 09 Jan 2006 at 06:57

MenTaLguY: Yes, because it is intended to be less verbose that XML and thus SGML /HTML documents. But not necessarily YAML ; any concise declarative language may do.

But what interests me is what the issues are when a procedural versus declarative choice isn’t obvious. I think available tools to support getting information out must be one factor. Since I’ve always found parsers difficult to get correct I have a leaning towards using code rather than data. This is probably because I’ve not found ways to make my data-to-be-parsed sufficiently simple. But maybe even with all the drilling of pilot holes and using countersink bits, it is still better to put things together with screws than nails.

said on 10 Jan 2006 at 04:17

How about amrita.sourceforge.jp!?

Comments are closed for this entry.