Skip to content

Documentation improvements #368

Closed
kristianmandrup opened this Issue Dec 6, 2012 · 8 comments

3 participants

@kristianmandrup

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
...
end
@steveklabnik
drapergem member

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.

@kristianmandrup

How about this then?

class Draper::Decorator
    class << self
      alias_method :decorate, :new

      def self.lazy!
        self.send :include, Draper::LazyHelpers
      end
    end
end

class MyDecorator < Draper::Decorator
  lazy!
end

or perhaps even: roles :lazy ?

@steveklabnik
drapergem member

Seems like a lot of effort to drop off like ten characters. Hm. Are there other roles a Decorator might play?

@kristianmandrup

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 ;)

@steveklabnik
drapergem member

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...

@kristianmandrup

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 ;)

@steveklabnik
drapergem member

Right, but polluting the global namespace is bad. See rspec changing to the expect syntax, for example. DSL != 'define methods on Object'.

@kristianmandrup

I would never opt to pollute the global namespace!!! Of course not ;)
Same goes for any language where this is even possible, such as Javascript.

@haines haines added a commit that closed this issue Dec 31, 2012
@haines haines Rewrite README
Closes #364
Closes #368
Closes #371
[ci skip]
52360b6
@haines haines closed this in 52360b6 Dec 31, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.