On Wednesday, October 13, 2010 07:03:04 pm Dave Howell wrote: > On Oct 13, 2010, at 14:46 , David Masover wrote: > > I certainly don't see how abandoning the idea of > > > > separating logic from presentation wholesale is better. > > Neither did the people on the Sequel list. But I should say that I didn't > abandon separating logic from presentation. It was my MODEL that ended up > having to handle most of the presentation that kept climbing out of Haml. To be honest, that sounds even worse. I push most of the logic back into the model and most of the presentation into the view, leaving controllers mostly for routing requests and authentication. > >> It's a program for a pharmaceutical company to track their products, > >> processing, and inventory. My PostgreSQL schema uses a custom data type > >> ('percentage' which is a numeric(5,2) that cannot be set above 100.00 or > >> below 0.00), > > > > Huh. DataMapper does support custom, user-defined types, though I'm not > > sure how easy it is to do that with an existing adapter. (To give you an > > idea, there is currently a working DataMapper adapter for Google App > > Engine.) > > I found all kinds of indications that even ActiveRecord *could* do what I > wanted. But in the end, whether or not something is *possible* is > completely irrelevant in the face of "can *I* make it do that in a > reasonable amount of time?" I absolutely agree. However... > Sequel's documentation kicks titanic > ass, though: far and away the best I've ever gotten with any Ruby-related > thingamabob. Well written and well organized RDoc-y parts, AND extensive > walk-throughs, examples, and discussions, all installed right on my > system, plus a developer whom I've seen easily answer questions that made > my eyes cross. In terms of developers, I've seen the same with DataMapper... Anyway, getting to the point: > HAML's documentation *looked* really good at first, but that's because it's > good at telling you what it thinks you should know. It was completely > silent on how to make it process the contents of a variable as HAML, or to > otherwise get it inserted *before* interpretation. So, I hate to say it, but... These things are open source. The source is open. More than that, Haml has a decent test suite, which is always a good place to look when you want to know how to use some code. It took me about three minutes to find this: http://github.com/nex3/haml/blob/master/test/haml/template_test.rb In particular, this line: Haml::Engine.new(File.read(File.join(TemplateTest::TEMPLATE_PATH, "_#{name}.haml"))).render(self, locals) Seems to me that you'd just replace the "File.read" part with the source of whatever you're trying to render. Note that this will likely be _much_ more efficient if you can keep the Engine object around, and that's true for any template system, which is probably why it makes more sense for you to take whatever you were going to do here and put it in a partial... Now, granted, that should only ever be a stopgap solution. After getting that working, the immediate next thing would be to bother the list with, "Hey, I got this working, is this likely to continue to work? If not, how can I get it working?" But the point is, while good docs are a good thing, I think working and readable code is at least as important. If the docs are almost completely comprehensive, but the code is shitty, I'm screwed as soon as I manage to ask a question the docs can't answer. If the docs are a good starting point, but the code is solid, I have confidence that I can answer _any_ question. If the docs are absolutely worthless, I can't even get started. So it seems to me like the ideal amount of documentation is enough to get started, and more only if people have time, or where the code is particularly unclear. By the way, I generally only allow this excuse for libraries. If I'm programming in Ruby, I'd better be able to read Ruby code. The same is NOT true if I'm a user -- I should NEVER have to dig into the code of nginx.