Thanks for the feedback Aaron; I'm excited to check out (and hopefully
contribute to) your UI kit.
---
I concur with the idea of multiple behaviors requiring the syntax you
noted, and custom tags would not deal with that. However, I find that in
most of our use cases, probably 95% of our tags with behaviors include just
one behavior.
I believe one could implement custom tags using a pattern similar to the
stub below, and if one did so, enable a jQuery guru to implement a custom
tag that 'plays nicely' with Behaviors without adopting Moo:
var BehaviorProto = Object.create(HTMLElement.prototype);
> BehaviorProto.createdCallback = function() {
> // register the element with Behaviors, so the $$([data-behavior] is not
> necessary for this custom elements based on this prototype
> };
var Popover = document.registerElement('pop-over', {prototype:
> BehaviorProto});
then:
<pop-over>My content here</pop-over>
or
<pop-over data-popover-options="{...}">My content here</pop-over>
My goal is to reduce the learning curve with use of behaviors by "power
users", so the semantic changes, while small, may (I hope) measurably
reduce the learning curve.
Cons:
- requires a browser supporting custom elements / polyfill
<http://www.polymer-project.org/platform/custom-elements.html>
- does not lend itself to multiple behaviors
- for behaviors where options are specified as JSON, don't think I've
really reduced the notably
Pros:
- nice semantics
- reduced learning curve for simple behaviors
As I wrap up this post, I think I may be talking myself OUT of doing this,
since I'm not really sure nice semantics are worth the effort :-)
Anyway, food for thought such as it is.
Eric
On Monday, June 23, 2014 3:02:54 PM UTC-4, Nutron wrote:
>
> Allo.
>
> There's no reason that behavior wouldn't work with custom tags, though
> it's not designed to work with them as semantic replacements for the
> behavior listing itself. For example:
>
> <foo> I'm a foo </foo>
>
> wouldn't translate into Behavior instantiating it as a Foo. Instead you'd
> have to do:
>
> <foo data-behavior="Foo"> I'm a foo </foo>
>
> This is ideal for two big reasons:
>
> - You might have more than one behavior for the tag (both Form.Request
> and Form.Validator, for example)
> - You only have to do one DOM search to find them all
> ($$('[data-behavior]')). This search is far more scalable than having to
> do
> a DOM search for each behavior you write.
>
> On an unrelated note, I've been working towards open-sourcing our UI kit
> here where I work. There's still a lot of work to do (we have a bunch of
> demos we hope to get online as well as docs and css/less files that
> accompany them), but you can at least see what's in it now:
>
> https://github.com/Behavior-UI/behavior-ui/tree/master/js/Source
>
> -aaron
>
>
>
> On Mon, Jun 23, 2014 at 11:21 AM, Eric Patrick <patric...@gmail.com
> <javascript:>> wrote:
>
>> Has anyone experimented with porting Aaron's behaviors
>> <http://www.clientcide.com/code-releases/bootstrap-3-0-clientcide-3-1-0-behavior-1-3-0-and-more-behaviors-1-0-8/>
>> to
>> HTML5 custom tags
>> <http://www.html5rocks.com/en/tutorials/webcomponents/customelements/>?
>>
>> Our toolset targets business 'power users' who are not js experts, but do
>> learn basic markup. I've found behaviors are a very powerful tool in
>> enabling this user base to achieve things that normally require
>> 'traditional' coding.
>>
>> However, we also have client shops with JS expertise (usually jQuery),
>> and I am weighing porting our custom behaviors to HTML5 custom tags, and
>> allowing JS devs to create new custom tags following a similar structure
>> using jQuery, instead of requiring MooTools.
>>
>> (I continue to love Moo; just trying to leverage existing knowledge bases
>> out there. I'm in an enviable position of generally dictating the browser
>> to our user base, so I get to ensure an evergreen
>> <http://tomdale.net/2013/05/evergreen-browsers/> browser.)
>>
>> Anyway, just wondering if anyone on this list has weighed pros and cons
>> of such an approach, of if you might be interested if I just put this in
>> GIT for joint development?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "MooTools Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mootools-user...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
---
You received this message because you are subscribed to the Google Groups
"MooTools Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mootools-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
