The decorated_association example should mention that you can specify a with: option, that defines the specific Decorator class to be used for the association in question. For any large project (more than say +10 models) this quickly becomes an issue.
Suggestion: The inclusion of the LazyHelper module could perhaps as well be encapsulated in a Draper::LazyDecorator in order to remove a little code noise?
class MyDecorator < Draper::LazyDecorator
Yep. Docs need lots of work before release.
I like the idea of a LazyDecorator, in a way, but it seems to me that the module is better. Laziness is more of a role than it is a subclass.
How about this then?
class << self
alias_method :decorate, :new
self.send :include, Draper::LazyHelpers
class MyDecorator < Draper::Decorator
or perhaps even: roles :lazy ?
Seems like a lot of effort to drop off like ten characters. Hm. Are there other roles a Decorator might play?
Well, I just feel it is kind of dirty having to add that include (more like 10 chars?) to most decorators. But hey, I will just make my own patch. I just thought other might have the same "concern". And sure, I think it would make sense to be able to register different kinds of roles with a Decorator, but then, I would just use my concerned gem for those cases and perhaps wrap it inside a roles macro. That is just my style of coding... I like to read my "published" code like a good book, while hiding away all the nitty-gritty details behind a magic curtain ;)
I guess I'm not sure that it's 'most', really. I personally don't even like LazyHelpers, I wouldn't have included them at all, but @jcasimir already did...
I see you point, but then again h.content_tag doesn't really feel that natural. Ruby is supposed to be more DSL like than fx Java IMO ;)
Right, but polluting the global namespace is bad. See rspec changing to the expect syntax, for example. DSL != 'define methods on Object'.
I would never opt to pollute the global namespace!!! Of course not ;)