I just brought _super and traditional controllers back. However, now
I am reconsidering that.
Here's an app made with out controller and super but still uses
inheritance. I just updated it to use traditional controllers.
http://cdn.javascriptmvc.com/videos/3_0/toolbar/toolbar.html
The functionality is 3 parts -> a toolbar, positionable, and menu
controller.
Toolbars basically open menus. Menus can open other menus. Menu
inherits from Positionable to get the ability to put itself elsewhere
in the DOM and to open / close. Toolbars call an "open" method on
menus, and menu's call "_super" to position themselves correctly using
positionable code..
But inheritance is a bad idea compared to modules. It's basically
"is_a" vs "has_a" relationships. I want to encourage people to build
widgets as collections of other widgets. Similar to "acts_as" in
rails. This idea is inspired by by the great Yehuda Katz:
http://gist.github.com/278694. In this article, he also makes use of
triggering events instead of calling methods.
Lets take a look at the shortcomings of the "is_a" approach ....
First, menu's are inexorably linked to positionable. What if you
wanted a menu that didn't use positionable. Maybe you just needed to
hide / show. How could you do that?
Second, what if you wanted something else to happen on open / hide ?
You would have to inherit from menu controller, make your own menu
controller, and make Toolbar controller use that. UGGGGG!
Now, lets think about how "has_a" solves these problems.
First, A 'position-less' menu is easy. It's just a menu w/o
positionable on it. Just don't add positionable to your element.
Second, To make something else happen on open, you just have to make
that element "has_a" your other plugin.
Importantly, all communication has to happen through events. You
should trigger and listen for events. This is the API.
But, there are some problems .....
To make a toolbar with the old system, I just have to do $
('#toolbar').toolbar();
This is b/c toolbar knows which plugins to create.
With the new system, I'd have to do something more like:
$("#toolbar").toolbar().find('ul').menu().positionable()
Gross! I shouldn't have to do this to make a working toolbar. I
should just say 'TOOLBAR'!!!
So, somehow I've got to figure out how to distinguish is_a and has_a
type things in JMVC. I want to encourage people to make and share
many has_a widgets.
Only your 'application-level' components should be 'is_a'. These are
things extremely specific to your functional requirements and the DOM
they operate on.
I'd like some type of "acts_as" class of plugins.
$.controller("my.toolbar",
{
acts_as_jupiter_toolbar : { menuTypes: [jupiter.menu,
jupiter.positionable],
menuSelector : "ul"
itemSelector: "li" },
acts_as_sortable : {sortOn: ".sortable"},
},
{
menu-open : function(el, ev, menu){
if(el.text() == "bad choice") while(1) alert("bad choice");
}
})
$("#toolbar").myToolbar();
Acts as could be almost just like controllers:
$.actsAs('jupiter.menu',
{
triggers: ["menu-open"] //allows actions named "menu-open" to be
wired up on Controllers that act_as jupiter.menu
},
{
init : function(el, options){ //options passed from acts_as
arguments
... configure ...
}
})
--
You received this message because you are subscribed to the Google Groups "JavaScriptMVC" group.
To post to this group, send email to javasc...@googlegroups.com.
To unsubscribe from this group, send email to javascriptmv...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javascriptmvc?hl=en.
> <alexandre.r...@gmail.com>wrote:
> ...
>
> read more »