You picked the same part of Angular that gave me the most doubts when I was
considering this syntax and Angular in general, which is not a coincidence,
I think. And you do have a point - there is an inconsistency in this
particular part. What nicely illustrates the inconsistency, is the fact
that our production apps use "novalidate" attribute on most forms, because
otherwise normal browser validation interferes with ours. I first thought
about the form problem when I considered that it just feels wrong to set up
validation rules in views, when a View should not know about Model. We
use form validation attributes of HTML because we are used to it, but that
is not MVC \ MVVM. The right solution, of the top of my head, would be a
syntax like <form ng-form="mainCtrl.form">....</form>, and I would also
like to be able to do form.inputName.addValidationRule("ng-required",
function(){ return requiredIndicator1 || requiredIndicator2 ;}); inside
that controller initialization function.
Another lesson hard learned for me is the following (names are
generalized): just today I was working on a controller, because
api.updateEntityPart(bizData, $scope.entityId); failed The problem was -
the entityId was undefined, because it was named $scope.entityFullNameId by
the controller that attached it (a recent rename). In order to find it and
verify the bug, I had to breakpoint my Chrome and examine the whole $scope
chain, some 4 or 5 parents long. had it been attached as
$scope.entityCtrl.entityId - and I would know where to look the moment I
saw it. Better yet, the bug could be avoided altogether, since a search for
"$scope.entityCtrl" would show up any controllers dependent on it in the
inheritance chain. This approach allows us to easily detect external
dependencies on a controller and work out its expected interface.
As a final suggestion - suppose someone deleted $scope.entityFullNameId =
x; from its controller altogether - we would suddenly be left with a
controller dependent on a missing part with no clue as to who was supposed
to provide it in the first place (short of restoring our version from
yesterday and examining it).
On Tuesday, December 17, 2013 8:29:05 PM UTC+2, Kay wrote:
> The "controller-as" syntax raised some inconsistencies to the framework's
> design decisions which, I believe, need to be addressed or at least
> clarified.
>
> One of the issues is that special models that are generated by the
> framework, eg. item in ng-repeat="item in main.items", or
> form.email.$valid in <form name="form"><input name="email"
> type="email"></form> are still being put under $scope regardless of the
> "controller-as"
> syntax, so conceptually there is now two competing model containers storing
> interrelated information that should really be integrated as a single
> whole. However you also probably won't wanna hook these special models
> under main (or other controller instance alias) because ng-repeat="main.item
> in main.items" or main.form.email.$valid are just way too verbose and
> stupid.
>
> It seems to me that while the "controller-as" syntax (btw, we need a
> better name than that to refer to this feature...) solves a certain
> problem, ie. the primitive type binding issue, it's hardly a beneficial
> addition to the integrity of the framework, and is probably introduced
> majorly for the sake of AngularDart or some Google coding styles.
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.
