Actually what’s happened is that you don’t explicitly give a this attribute anymore. So the correct def is now:

<def tag="name"><%= this.name %></def>

I should fix the post!

(done now)

<def tag="name" attrs="this"><%= this.name %></def>

will throw the following error:

invalid attrs in def: this

To fix, replace ‘attrs’ with ‘attr’.

<ul_for attr="tasks"><name_link/></ul_for>

Are you referring to the common >XML dillemma of whether to model >some piece of data as an element >or an attribute?

Yes, such as for “tasks” and “name_link” in the example
for attr=”tasks”>link/>for>

I still don’t see the net value in using DRYML and would appreciate some clarification from you on these counts:

1. It seems to be a regression to dump a richly-expressive language like Ruby in favor of XML/DRYML. With XML/DRYML, you essentially have to contrive XML elements for various Ruby language constructs such as loops (I noticed you have a ), conditionals such as if-then-else, case statements etc, some of which can get awkward and very error prone (users of BPML like me have been bitten by this in the past).

Would you advocate changing Rake to use XML instead of Ruby(a la Ant)?

1. XML/DRYML seems to be a way to limit the usage of Ruby code in Views. But that should be so by design: anytime you’re writing more than a little Ruby code in a view, you ought to move it away into a helper file. Your way seems to be to move it out into a taglib. So is it really buying much as opposed to following good design practice.

2. As for the benefit of conciseness, there are other ways to get concise with your view code without eliminating Ruby – see HAML for example (http://haml.hamptoncatlin.com).

Would appreciate hearing your thoughts.

In a future version Hobo will know what the standard HTML tags are (i.e. we’ll simply hard-code a list of known HTML tags), and all other tags will convert to method calls. So you will in fact get an error if you try to use ul-for.

Your other point is a little un-clear: “whether to make it an element or an attrib”. Are you referring to the common XML dillemma of whether to model some piece of data as an element or an attribute? I don’t think that problem arises in DRYML. I’d be interested to hear a clarification on this point.

Regarding your conclusion that overall eRB is quicker and easier to maintain, I’d say you need to back that up a bit more. I’m using DRYML in several big projects at the moment, and my experience is quite the opposite. DRYML is slashing development time rather dramatically.

Thanks

Tom.