Closed wilsonpage closed 11 years ago
It's like going full circle lol!
:+1:
Bugsy not me to have to go through and replace 'id' with 'slot' everywhere in the we bapp.
I'll do it :dancers:
We could then look towards an api like:
var layout = new Layout();
var apple = new Apple({ slot: 1 });
layout
.add(apple)
.render();
// ... some time later
// Change slot
apple.slot(2);
// Rerender
layout.render();
Also be able to get slot:
apple.slot(); //=> 2
:recycle:
This has been implemented, although there is no View#slot()
API as of yet.
One thing that has been bothering me for a while is trying to communicate the concept of ids. Currently when placing a view into a parent template we use the id like so:
The annoying thing about this is that ids have to be unique within the entire view so we can't just simply give our views
id: 'slot_1'
as there may well be another view in the layout with the same id. This means that queries usinglayout.id('slot_1')
would return unexpected results.Proposition:
id
becomes an optional parameter to be used for queries onlyslot
becomes a required parameter that refers simply to the view's placement inside the parent.This means markup can become a lot cleaner and the dev no longer has to worry about their ids conflicting.
Child view modules can switch slots (positions) in the view without having to change their id. This makes modules more transportable. Effectively we have split the two jobs
id
previously had, and broken it in two.When to use ids?
If we went ahead with this, most views would rarely ever need to be given an id. Think of it as an
id
attribute in html. You would only need to add one if you needed to uniquely query for a particular view.When to use slots?
If a view is to be nested inside another view, it will require a slot. If a view has no parent, it would not require a
slot
attribute, as it is not being placed in a slot.