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 <[email protected]
> <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 [email protected] <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 [email protected].
For more options, visit https://groups.google.com/d/optout.
