I am currently working on it. I want to introduce this in the v0.7.2, hopefully in a week or two. All depends on the weather over the weekends 
In this release system will generate warnings about undeclared handlers, but it will still work. In 0.8, I am going to completely depreciate it.
Thanks for your answer Grych. Thats true that returning sockets would be a nice improvement and generate less code and grouping instructions would be great ! If I may add, I think that replacing the whole element classes is a bit heavy, should be a method to add or remove a specific class or attribute (like jquery)…
For partials i couldn’t find a way to use it (I generate n times the same partial which is a button). If you have a chance to show a demo that would be great… Anyway thanks !
I will think about it. By the other hand, I don’t want to overcomplicate Drab.Element - it is supposed to be the simplest one.
Did you check Drab.Query - the drab library over jQuery? You may find it useful, if you are using jQuery. It has the class manipulation functions.
This is exactly what the next release will be about.
This was kinda hard to accomplish, but now I think I found the way how to do it with an elegance. With Drab, there are three ways to update the content of the page: using the assign name (Drab.Live), with the CSS selector (all other modules) or just send javascript (Drab.Core.exec_js). If you use exec_js, you know exactly what you’re doing, and there is no help from the Drab side More interesting are those two update types:
Having the page as below, we want that clicking the button updates .spaceholder1 only within the range of drab-commander.
<div drab-commander="DrabTestApp.Shared1Commander">
<div class="spaceholder1">Nothing</div>
<button drab-click="button_clicked">Shared 1</button>
</div>
<div drab-commander="DrabTestApp.Shared1Commander">
<div class="spaceholder1">Nothing</div>
<button drab-click="button_clicked">Shared 2</button>
</div>
Now, you can accomplish it by passing additional arguments, like output tag id, but it is not very flexible. What if we could select just this drab-commander tag, where the button was clicked? Just like we can use Drab.Core.this/1 to select the exact sender of the event, we may have Drab.Core.this_commander/1, to build a selector which choses the desired object:
defhandler button_clicked(socket, sender) do
set_prop socket, this_commander(sender) <> " .spaceholder1", innerText: "changed"
end
Notice the space before “.spaceholder1”. this_commander/1 returns the string like [drab-id="f59d54e6-a924-4e72-90d1-5177efecac9b"], so you may build any selector based on it.
However, where using living assigns, we are not using any CSS selectors - everything updates under the hood. In this case, this functionality will be always turned on. Every update inside the drab-commander will be regional by default.
<div drab-commander="DrabTestApp.Shared1Commander">
<div><%= @assign1 %></div>
<button drab-click="button_clicked">Shared 1</button>
</div>
<div drab-commander="DrabTestApp.Shared1Commander">
<div><%= @assign1 %></div>
<button drab-click="button_clicked">Shared 2</button>
</div>
And the handler is just exactly as it was before. Local changes are out of the box.
defhandler button_clicked(socket, sender) do
poke socket, assign1: "changed"
end
I believe it makes sense and finally provides a way to create a kind of reusable components.
One more thing: why not to enable this functionality with the selector updates by default? I wanted to do it like this, but I realized that it would provide way too much magic. When using a selector, you expect some behaviour.
This release introduces core API changes, and the important new feature: step forward to reusable components!
use Drab.Controller is now optionalWhen using default commander name, corresponding to the controller (like PageCommander → PageController), there is no need to mark controller as Drab.Controller anymore.
All shared commanders must be explicitly declared in the controller:
use Drab.Controller, commanders: [My.Shared.Commander]
In this version, system generates warning message if commanders are not declared. This warning will become error in v0.8.0
defhandler macro for creating event handlers in commandersSince this version, all event handlers, whenever they are in shared or “normal” commander, must be declared with public or defhandler macro. Use defhandler instead of the standard def.
This:
public :button_clicked
def button_clicked(socket, sender), do: ...
is an equivalent of:
defhandler button_clicked(socket, sender), do: ...
In this version, system generates warning message if the function is not declared as handler. This warning will become error in v0.8.0
Accomplished this with the new Drab.Core.this_commander/1 function, returning the unique selector of the sourrounding commander tag, so you may easly reduce the region where your update works.
Having the page as below, we want the button to update .spaceholder1 only within the range of drab-commander.
<div drab-commander="DrabTestApp.Shared1Commander">
<div class="spaceholder1">Nothing</div>
<button drab-click="button_clicked">Shared 1</button>
</div>
<div drab-commander="DrabTestApp.Shared1Commander">
<div class="spaceholder1">Nothing</div>
<button drab-click="button_clicked">Shared 2</button>
</div>
Just like we can use Drab.Core.this/1 to select the exact sender of the event, we may have Drab.Core.this_commander/1, to build a selector which chooses the desired object:
defhandler button_clicked(socket, sender) do
set_prop socket, this_commander(sender) <> " .spaceholder1", innerText: "changed"
end
Notice the space before “.spaceholder1”. this_commander/1 returns the string like [drab-id="f59d54e6-a924-4e72-90d1-5177efecac9b"], so you may build any selector based on it.
What about when a shared commander loads ‘another’ shared command, like doing in-page navigation to other ‘components/pages’? Does that mean you have to list all possible shared commanders on all possible controllers?
Yes.
Drab needs to know all the commanders playing the role in that scene, if we need to unify shared commanders with page ones, to get callbacks working.
But, I’ve got your concerns now. It might be a loooooong list sometimes.
What about allowing any shared commander, but callbacks working in the declared?
BTW. This is why I am constantly spamming you guys on new ideas and features. I am working on Drab by only myself, so any other opinion is highly appreciated!
Could always tag a shared commander with @public or something to have it ‘always be in scope in a controller’ or so?
Heh, well if you are curious, this is slowly replacing the old usages of the erlang web framework Nitrogen.
In essence with nitrogen everything was ‘components’, which you could swap and replace and do all kinds of things on a page (and it mostly gracefully fell back without javascript too, mostly, depending on how you coded your side), and you built a page with an initial set of components (which could then do all manner of stuff inside their own little areas). They sent html with embedded javascript initially, but acted a lot like drab overall (though in Erlang).
Maybe take a look at nitrogen, see if you get some ideas of ‘how’ to use it (not necessarily it’s implementation or API though).