Hi Daniel,
Thanx for feedback. Some comments inline
Субота, 28 грудня 2013 р. 03:35:47 UTC+1 користувач Daniel Tabuenca написав:
>
> Element directives are great for stand-alone widget-like things, but are
> not very easy to compose. It is very much desirable to have multiple
> directives on a single node. For example how would you write this using
> only element directives:
>
> <a ng-class="{important: customer.isVIP}"
> ng-click="selectCustomer(customer)" ng-hide="customer.isHidden">Click To
> Select</a>
>
> As you can see, attribute directives are much easier to compose together
> in a single node. How would you write the equivalent using only element
> directives?
>
not, I don't really write things like example above, especially things like
ng-click. So you have two tasks here - render and behave. In current
templating we use the equivalent would be:
<gui:template mode="customer-action" type="models.Customer"
behaviors="behaviors.SelectCustomer">
<a class="customer-action {{customer.isVIP() ? 'vip' :
'normal'}}-customer-action {{customer.isHidden() ? 'hidden' :
'visisble'}}-customer-action">Click to select</a>
</gui:template>
or a more verbous version (which I lke better)
<gui:template mode="customer-action" type="models.Customer"
behaviors="behaviors.SelectCustomer">
<a class="customer-action">
<gui:class value="{{customer.isVIP() ? 'vip' :
'normal'}}-customer-action" />
<gui:class value="{{customer.isHidden() ? 'hidden' :
'visisble'}}-customer-action" />
Click to select
</a>
</gui:template>
there is even more verbous version :) (it's quite expressive though)
But to some up in general I don't really belive in abstractions that are
augumentation of exisiting ones and even with chaining - they are
confusing, your <a> tag template says very few about it's semantics, while:
<ng:selecting-link target="{{customer}}">Click to select</ng:selecting-link>
> Furthermore I don't think a lot of the benefits you list for element
> directives are entirely accurate.
>
> In terms of posibility of clashing of directive names, both attribute
> directives and element directives will clash equally. For example:
>
> <tabs></tabs>
> <div tabs></div>
>
> These will both instantiate a directive called 'tabs' and will clash with
> any other attribute or element directive called "tabs" defined in any other
> module. So in this regard there is no advantage to using the element
> directive to the attribute directive other than visual style/asthetics.
>
Um I think you missunderstand me - there is more chance your dirrective
interfaces or side effects clashes:
* it's quite possible to write directive adding class or style while in
the same time unrelated directive affects same
* it's quite possible to define additional attribute name (parameter for
directive) that clashes with other directive
> In terms of handling of parameters, both element directives and attribute
> directives treat attributes in the exact same way. The following are
> equivalent:
>
> <tab tab-title="My Tab"></tab>
> <div tab tab-title="My Tab"></div>
>
> The element directive version is no more "namespaced" or protected from
> clashing as any other attribute-type directive. The attribute "tab-title"
> is as much of an "invented syntax" in the element directive as in the
> attribute directive.
>
Well they are - I can easily use <tab title=""> while using <div title=""
tab> is of ambiguous semantics.
> Finally, there is no difference as to the type of content an element or
> attribute-based directive can hold. The reason for ng-repeat-start and
> ng-repeat-end is simply a choice made by the developers to allow for not
> having to wrap the repeated content in its own node. But you could easily
> write your own directive:
>
> <my-repeat repeat-expression="person in persons">
>
> <p>Hello {{person.name}}</p>
> <p>How are you?</p></my-repeat>
>
> The equivalent with attribute syntax would be something like:
>
> <div my-repeat="person in persons">
>
> <p>Hello {{person.name}}</p>
> <p>How are you?</p></div>
>
> As you can see, in both cases the directives can contain a document
> fragment. Also, notice that in the <my-repeat> version I need to invent a
> repeat-expression attribute for the expression, while in the attribute
> version I can use the my-repeat attribute itself.
>
Well that's the problem - in example above you require wrapper to have two
<p>'s, what if those are two li's? or two tr's? (last one you could argue
to put in tbody but belive me it has consequences) So you don't have really
nicely scalable directive but instead a combination of nice and ugly, which
as I mentioned makes processing more complex (by processing I mean external
analysis of templates, like cyclomatic complexity for example). What would
be wrong with this:
<gui:for-each items="{{items}}" var="item">...</gui:for-each>
I now can easily extract the variable name, I can easily compute expression
in isolation without having to interpret new DSL, I can even scale to the
following silly case:
<div>
<gui:for-each items="{{classes}}" var="class"><gui:class
value="{{class}}" /></gui:for-each>
</div>
So except for verbosity (and any decent IDE removes that problem) i don't
see how attribute version is superior to the element version.
> Hopefully, I helped you understand a bit better why attribute is the
> default choice for directives. Element directives can be great for making
> higher-level components (e.g. tabs, tabpanes, layouts, etc...). In
> particular, element directives usually should include their own template
> that replaces the entire element with new HTML. The advantage to using
> element is purely asthetic though. You can pretty much achieve everything
> you can do with element directives using attribute directives, but you
> can't achieve everything you can do with attribute-directives by using only
> element directives.
>
I'm very much for semantics and that's where they differ. And as for
directives for non componentization puposes (ngHide, ngMousedown, etc.) I
will start separate topic probably - to me they fill like in a wrong place
- they should not be directives.
> One additional thought, is that using element directives requires some
> special handling in older versions of IE to make them work, so if you must
> support IE this could be a concern.
>
Do you know exact versions? IE7 is still of a bit of concern. In our
internal templating we just use XML and not HTML which plays very nice.
In any case thanx for feedback.
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to angular+unsubscr...@googlegroups.com.
To post to this group, send email to angular@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.
