| Entwine: Best practices for code organization | Uncle Cheese | 9/21/12 8:12 AM | I'm just starting to get into Entwine, and I'm loving so far how much more organized my code is. One thing I find myself wanting to do a lot is define everything related to a given component under one entwine definition. As an example, I'll illustrate building an accordion component the standard way: $('div.accordion').entwine({ onmatch: function() {this.find('.panel').close();} // etc.. }); $('div.accordion .panel').entwine({ close: function() {....} // etc }); $('div.accordion h3 a').entwine({ onclick: function() {.....} // etc }); I tend to think of the div "accordion" as a class with its own methods and properties, e.g. $('div.accordion').closeAll(), but having to write separate entwine() definitions for every DOM element related to the accordion feels like a shortcoming. I'm wondering something like the following would be acceptable. (I'm guessing it's an abomination of the onmatch constructor). $('div.accordion').entwine({ Panels: null, Buttons: null onmatch: function() { this.setPanels(this.find('.panel')); this.setButtons(this.find('h3 a')); this.Panels.entwine({ close: function() {....}, open: function() {....} }); this.Buttons.entwine({ onclick: function() {....} }); this.Panels.close(); } }); I'm not even sure if that code works. It's just a rough idea of what I want. Doesn't it just feel better to have everything under one roof, so to speak? |
| Re: [silverstripe-dev] Entwine: Best practices for code organization | Sam Minnée | 9/21/12 3:25 PM | I can't answer this myself but I know that Hamish has been working on Entwine docs recently that will hopefully cover this.
|
| Re: [silverstripe-dev] Entwine: Best practices for code organization | Hamish Friedlander | 9/23/12 3:00 PM | Hi, Don't do that :). Specifically, when you bind with Entwine you're binding to a _selector_, not a set of elements, so this.getPanels().entwine({ ... }) won't do what you expect.
I've been working on a nesting pattern that'll solve your problem a bit better. It'll look like this:
$('div.accordion').entwine({
'.panel': { close: function() { ... }
})
});
It's a slight backward incompatibility (you can currently assign objects to properties, but you probably shouldn't because of the all-element-share-the-same-instance problem). As Sam mentioned, I'm working on a new site with lots of docs that will hopefully explain the fundamentals better. You can check out progress on my github at https://github.com/hafriedlander/entwine.js.site
Hamish Friedlander --You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group. |
| Re: [silverstripe-dev] Entwine: Best practices for code organization | Uncle Cheese | 9/23/12 4:14 PM | Brilliant! I love the docs and the new API you're describing. I think that will go a long way to making Entwine a mature JavaScript design pattern.
Aaron |