{{{
I just “released Apotomo 1.2”:https://github.com/apotonick/apotomo/commit/1212694f9b76d3781186a9a5f412008ca57cdecd today. Yeah. People screaming, clapping, hooting, going nuts, I can hear it. Ok, this release is nothing special, but it fixes a severe bug. No, it wasn’t just a bug, it was more, *it was a design flaw!*
h3. What’s new?
Nothing. I already said that. However, in the last release we added some option that allowed the following.
responds_to_event :click, :passing => :root
The @:passing@ option makes it easier to attach event handlers to other widgets, for instance, @:root@. This worked fine on a 2-level setup, but having deeper widget trees, “this failed”:https://github.com/apotonick/apotomo/issues/34 silently.
The problem – in short – was that the parent widget _sometimes_ wasn’t available yet when the child set up its event handlers. The fix: The constructor @Widget.new@ now requires the *parent widget as the first argument*. Makes things way simpler and explicit.
h3. What can I do with that?
Well, you now can safely use the @:passing@ option anywhere. You can also use @root@ and @parent@ in your @has_widgets@ blocks now. They will be what you expect.
class CommentsWidget returns the real root me.parent # => well, yeah...
All in all, the new constructor makes the Apotomo core a lot cleaner and more understandable.
h3. What changed?
Be warned that @widget@ doesn’t return a real widget instance anymore (line 3). Don’t be worried, you have plenty of ways do to what you want.
has_widgets do |root| root << widget(:comments) # This still works. widget(:comments).markup! # This doesn't. root[:comments].markup! # This works, of course. comments = CommentsWidget(root, :comments) # works. comments.markup! # yepp, works.
Remember, you’re free to use the real constructor in a @has_widgets@ block (line 7) if you need to grab the created instance for whatever reason. You could also use the block for that.
has_widgets do |root| root << widget(:comments) do |comments| comments.markup! end
In short, the @<< widget(..)@ syntax now is a DSL construction, what happens internally is a call to the actual constructor. Easy.
The second big change is that *we got rid of the @after_add@ hook*. Since widgets receive their parent explicitely in the constructor, there's no need for a hook after adding a widget. Use the @after_initialize@ hook for that.
Check the "CHANGELOG":https://github.com/apotonick/apotomo/blob/1212694f9b76d3781186a9a5f412008ca57cdecd/CHANGES.textile for further notes and let me know if the changes work for you.
Kevin- thanks for donating 😉 LOVE to Austin!
}}}
Thanks for a great change, Nick! I especially like the block to grab the created instance (in your last example above). To add children to a parent, can we use either the block or the real constructor to grab the created instance?
LikeLike
Ah, I should have read the release notes! So your last example should be `CommentsWidget.new(root, :comments)` — I like this new method for adding children to parents. I’ll give the new release a try right away and let you know how it goes!
LikeLike
@Kevin: No no, the
root << widget(..)
still works, but if you need to work on the created instance itself, you use the constructor instead, or the block.LikeLike
So just to be clear, to create a parent-child relationship I could either:
root << widget(:comments) do |comment|
comment << widget(:track_back)
end
or
comment = CommentWidget.new(root, :comments)
comment << widget(:track_back)
yeah? If so, I like the block version, looks cleaner and more Ruby like, lets me do other things to use and abuse the instance object. X)
LikeLike
What this means to those new-ish to apotomo…
What used to be (in rspec)…
subject { widget(:some_widget) }
… is now …
subject { SomeWidget.new controller, ‘widget_name’ }
LikeLike