I'm reading EcmaScript specification.
At 9.2.12, there are:
11.Let varNames be the VarDeclaredNames of code.
12.Let varDeclarations be the VarScopedDeclarations of code.
And at 13.1.5 and 13.1.6:
13.1.5 Static Semantics: VarDeclaredNames
Statement :
EmptyStatement
ExpressionStatement
ContinueStatement
BreakStatement
ReturnStatement
ThrowStatement
DebuggerStatement
Return a new empty List.
13.1.6 Static Semantics: VarScopedDeclarations
Statement :
EmptyStatement
ExpressionStatement
ContinueStatement
BreakStatement
ReturnStatement
ThrowStatement
DebuggerStatement
Return a new empty List.
They look like the same.So I want to know what's the difference between VarDeclaredNames and VarScopedDeclarations ? Can you give me some examples?
Thanks.
Those two static semantic rules search the AST for the same kinds of things: VariableDeclarations, ForBindings, FunctionDeclarations and GeneratorDeclarations. There's a lot of duplication (especially in methodology) indeed.
However, as #loganfsmyth mentions in the comments, they do return different data - different types of lists. While VarDeclaredNames returns a list of names (strings), VarScopedDeclarations does return a list of declarations (i.e. AST nodes).
This is apparent in the sections where something is actually appended to the lists: §13.3.2.2, §13.7.4.5, §13.7.5.7, and §13.2.9 all do refer to the BoundNames of the respective element, while §13.3.2.3, §13.7.4.6, §13.7.5.8, and §13.2.10 do refer to the respective declaration itself.
Why is this distinction needed? The VarDeclaredNames are used to create the bindings in the scope, while the VarScopedDeclarations are used to find the function declarations to create (and initialise the bindings with those values).
Could it have been simpler? Yes, surely - for lexical declarations, the scope initialisation description just iterates the declarations and gets the BoundNames of each. You might want to submit a bug to spec authors to use this approach for function-level declarations as well. See issue 1203 discussing this.
Related
I'm trying to make a <select> behave with single or multiple selection depending on a condition. So far I have tried:
<select
ng-model="data.model"
ng-attr-multiple="{{myCondition ? '' : undefined}}">
(here's a plnkr I have been testing with https://plnkr.co/edit/ACKBMZSJc2MVSJaDBGMY?p=preview)
But it won't work. Even leaving ng-attr-multiple alone won't work. What am I missing here?
https://docs.angularjs.org/error/$compile/selmulti
Binding to the multiple attribute of select element is not supported
since switching between multiple and single mode changes the ngModel
object type from instance to array of instances which breaks the model
semantics.
If you need to use different types of select elements in your template
based on some variable, please use ngIf or ngSwitch directives to
select one of them to be used at runtime.
How do I add a filter attribute to <iron-data-table? (Please post a plunk demo.)
I forked this plunk. Then I tried to add a filter by adding the following line:
<iron-data-table
...
filter="['item.user.name.first.length', '< 5']">
Which broke the plunk. Here is the new (now broken) plunk.
The documentation here describes the filter attribute as follows:
filter An array containing path/filter value pairs that are used to filter the items.
But it lacks an example of how to use it.
How do I add a filter attribute to <iron-data-table? (Please post a plunk demo.)
This isn't a very well documented feature:
Normally, you would go about using filter-by and filter-value properties in <data-table-column> elements, but you can also access the filter property directly.
When it comes to filtering items data source, there is only "contains" kind of filtering available. So, you pretty much can't do filtering based on string length like in your Plnkr with those. For more custom filtering functionality, you need to go using a function dataSource where you can do anything you want using the filters provided as arguments for the data source function.
Anyways, in case you want still to access filter directly and for example provide a default filtering value, you need to set the value to be an array of objects, which have a path and filter property:
this.filter = [{path: 'user.name.first', filter: 'donna'}];
Here's an example: http://plnkr.co/edit/KIefwLNHeinkOgERWOvZ?p=preview
today i had a discussion with my colleague. The question was whether to use the additonal value attribute for a single HTML checkbox or not.
My preffered way is using a single checkbox without a additional value attribute and in backend doing a check like if
if (request.getParameter(checkboxName) != null)) {
...
}
My colleague argues that is would be more transparent using a single checkbox with a additonal checkbox value attribute like value="true" and doing a backend check like
if (Boolean.valueOf(request.getParameter(checkboxName))) {
...
}
As we want to make a small convention about our internal checkbox handling im now trying to find a "best practise" but couldn't find yet. I saw so far only examples with multiple checkbox with the same name. In this case of course it makes sense for me to use different values.
For me it seems to be a bit overhead using a value attribute in case of a single checkbox since i get always a String with "on" if its activated/checked.
We are using a Java Servlet/JSP MVC environment and im not 100% sure if this "on" comes from ServletRequest.getParameter.
I see reasons for following either method, which means there's probably no noticable difference between them. Whichever you pick will work out fine; just make sure you pick one. You could flip a coin or do a thumbwar or something.
As long as a single approach is consistently used, both will work. Yours is less code and doesn't require boolean conversion, the other´s html is more consistent with multiple checkboxes but will also break if you put the wrong value for whatever reason.
You could always do a bit of both and insert values in html for clarity but check for != null in the code and get the best of both options.
It makes no difference server-side as long as you are not checking the parameter for having a specific value. By HTML5 definition, which just establishes the longstanding practice as the rule, a checkbox element has the value on by default. This means that your server-side code cannot distinguish between data coming from <input type=checkbox name=foo> and data coming from <input type=checkbox name=foo value=on>.
I'm just starting out in Razor, and my first inclination was to treat Helpers like .ACSX's.
Let's say I make a very simple helper:
#helper HowManySpans() {
<div>
<input type="text" name="txtLoops" /><input type="submit" value="how many?" />
#{ if (IsPost) {
var count = Request["txtLoops"];
var i = 1;
while (i < count) {
<span>Span ##i</span>
i++;
}
}
</div>
}
It works fine until I place two on the same page. I was expecting the compiler to emit the name of the elements prefixed like ASPX pages generally do, yknow, ctl00_Header_txtLoops or something like that.
I guess in a more argument-driven helper, I could use my arguments to prefix names myself, but I feel that still postpones the issue. If I had some dynamic helper that prefixed names with a certain argument, I could still only have one on a page with that argument.
Am I overlooking something painfully obvious?
Razor emits only the markup that is in the page. It has very little in the way of augmenting the markup. Razor v2 added conditional attributes, but that is still somewhat explicit on behalf of the developer.
One question I have is why do the elements even need unique names. In many modern HTML5 applications there is little need for elements to have unique names.
But, suppose, there is a need, there are two ways I can think of to do it:
Have the caller pass in a name or name prefix (as you suggested).
Create your own counter, and increment it every time the helper is called. The big question is where to save the counter's information. One logical place to save it would be the HttpContext.Items collection, which is a per-request "bag of data". Each time the helper is called it checks the Items bag to see what the current count is, increments it by 1, uses that number, and updates the bag.
this is part of an XML file I retrieve using AS3 E4X:
<links>
<link>
<label>Versions</label>
<href>http://mylink1</href>
</link>
<link>
<label>Configurations</label>
<href>http://myLink2</href>
</link>
</links>
I want to retrieve the values of labels, so I write:
document.links.link.label.text();
This returns VersionsConfigurations. I need this as Array ([Versions, Configurations]) but I would like not to use a loop. Is there any other way?
Well, this is a "don't try this at home" solution, but here you are. :)
You can use E4X search expression to do whatever you want to nodes of an XMLList.
This works as follows: someXMLList.(expression), where expression is any AS3 code that can access each node's properties and methods with no need of qualifying their names. For instance, you could do the following:
yourXML.descendants("label").(trace("label text: ", text()));
Note that I'm using text() here with no access . operations. Actually this will return an new XMLList for all nodes, where expression evaluated to true. Since trace() returns void, the resulting list will be empty. Internally there is of course a loop through all nodes of XMLLIst that is created by calling descendants() (or using .. operator).
You can construct your array the same way.
var doc:XML =
<links>
<link>
<label>Versions</label>
<href>http://mylink1</href>
</link>
<link>
<label>Configurations</label>
<href>http://myLink2</href>
</link>
<link>
<label>A label
with
multiple
line
breaks</label>
<href>http://myLink3</href>
</link>
</links>;
trace(doc.descendants("label").text().toXMLString().split("\n"));
/* Trace output (incorrect):
Versions,Configurations,A label
,with
,multiple
,line
,breaks
*/
var list:Array = [];
doc.descendants("label").(list.push(text().toString()));
trace(list);
/* Trace output (correct):
Versions,Configurations,A label
with
multiple
line
breaks
*/
That may be useful when performing some complicated searches on an XMLList. However in your case I think you should instead use simple splitting of a string representation or a regular expression as Shane suggests.
An alternative technique could be to use a regular expression, although this particular example is dependent on your labels always starting with a capital and otherwise containing only lower case characters.
var regex:RegExp = /[A-Z][a-z]+/g;
var inString:String = "VersionsConfigurations";
var outArray:Array = inString.match(regex);
trace(outArray.length); // 2