I am using IntelliJ, it understands, that {{foo}} is an interpolation in the formControlName-attribute. But in the name attribute it does not. IntelliJ thinks in the name-attribute, that {{foo}} is an array and that I am missing a : Like in {foo : bar}.
The code compiles just fine, is this an IntelliJ-Bug or am I just lucky that the compiler accepts it?
<input type="radio" name="{{foo}}" formControlName="{{foo}}">
Angular definitely allows interpolation in attributes, but the generally prefered method (mostly for read ability) is property binding. name="{{foo}}" <=> [name]="foo" more info here
So your provided code
<input type="radio" name="{{foo}}" formControlName="{{foo}}">
becomes
<input type="radio" [name]="foo" [formControlName]="foo">
and this should make IntelliJ stop complaining.
Related
I'm using ui-bootstrap-datetime-picker with angularJS. And i'd like to know if it's possible to set show-meridian options of time-picker directly inside timepickerOptions ?
...
<input type="text" class="form-control"
datetime-picker="MM/dd/yyyy HH:mm"
timepickerOptions="{'show-meridian': 'false'}"
ng-model="ctrl.date.value"
is-open="ctrl.date.showFlag"/>
<span class="input-group-btn"></span>
...
This is a plnkr which illustrate the problem.
Root cause of the problem is wrong naming style. To make your code work, you have to change camel-case to dash-delimited: timepicker-options instead of timepickerOptions (see my forked plunker):
<input type="text" class="form-control"
datetime-picker="MM/dd/yyyy HH:mm"
timepicker-options="{'show-meridian': false}"
ng-model="ctrl.date.value"
is-open="ctrl.date.showFlag"/>
The key point here is normalization process being done by AngularJS. Since HTML is case-insensitive, AngularJS cannot convert HTML attribute named timepickerOptions into scope variable timepickerOptions - because timepickerOptions in HTML is seen by AngularJS exactly like timepickeroptions; so, there is no chance for it to determine how to normalize this name. Thus, you should always use -, _ or : to delimiter different words in directive name when using HTML.
I am currently doing homework, and following the instructions the book gives me, but I can't get the required or pattern tags to work. I am creating a survey form, and trying to make an error come up when the user doesn't type in their name, receipt number, or email. Here is a portion of it.
<label for"receipt">Receipt number *</label>
<input name="receipt" id="receipt"
placeholder="re-nnnnnn"
required="required"
pattern="^re\-\d{6}$" />
A few things i see
the required attribute does not need a value, the existence of the attribute is what makes it required or not.
the - does not need to be escaped so use ^re-\d{6}$ for the pattern attribute
the issue with the notepad++ is that the language formatting/color-coding is not up-to-date with all the attributes.
<input name="receipt" id="receipt"
placeholder="re-nnnnnn"
required pattern="^re-\d{6}$" />
there is no need to write like that u can just write : required and it will work
and whats your pattern i don't catch that
I saw this on a question recently.
<input type="radio" mess="whats up" name="q1" value="A" class="correct"/>
I can't get what the mess attribute do, and I couldn't see any result on the internet. So what is the mess attribute for?
It can be called as custom attributes intended to store a piece of information (purely for developer puropse)but it not advisable.
Instead you can go for HTML5 custom data attribute like
data-mess="whats up"
It can be easily accessed with .data() in jQuery.
<input type="radio" data-mess="whats up" name="q1" value="A" class="correct"/>
See
$('.correct').data('mess') // to getch the value
$('.correct').data('mess', 'some value') //to update the value
FYI:*custom data-** is purely validated with w3c validator. Whereas not with yours.
There is no mess attribute, in the question he just used it to attr and get the value through JQuery.
For example:
checked = $('input:checked').attr('mess'); sets checked to whatever the checked input had on the 'mess attribute', as seen in the question.
Another example:
$('#BobDiv').attr('txt'); will return 'Bob' if your HTML is <div id = 'BobDiv' txt = 'Bob' />
As seen here, you have to amend it in your !DOCTYPE declaration, though.
It's just a way to store arbitrary data in the tag. It does whatever the programmer intends it to do. Some people prefer to add custom attributes via data-foo, others prefer this syntax.
I want to know is there any way to add a custom attribute to the a
HTML element.
For example ,
<input type="text" name="txtNAME1" displayName="dname1" />
In the above example the custom attribute "displayName" is not a
standard HTML attribute. So I want to know if I can define the same and push the intended value to the server and access the same attribute's value.
Thanks in advance!
Which language are you using? You can do this in C# using
<input type="text" name="txtNAME1" displayName="dname1" runat="server" id="test" />
Then, in the code behind:
test.Attributes["displayName"];
You can also access it in jQuery with
$('test').attr('displayName')
and send it through to the server via a handler.
I happened to write this:
<input type="hdnStatus" name="hidden" value="1" />
Instead of:
<input type="hidden" name="hdnStatus" value="1" />
I was surprised that the first line generated a text box with no correct type
specified.
If first line generates text box, then is the below line of any use:
<input type="text" name="tbox" value="" />
It definitely is. What I mean is that rendering engines should be smart enough to
reject any incorrect input. Such things always create confusion and problems.
How did that happen?
Is this browser's fault or something else?
Or it is something wrongly correct?
From the HTML 4.01 spec:
Attribute definitions
type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI]
This attribute specifies the type of control to create. The default value for this attribute is "text".
So it appears that your browser falls back to the default value for type if it is invalid. This seems like sensible behaviour to me.
All browsers (that I am aware of) will degrade to an input with type="text" if the type attribute is not valid.
Some people have even advocated using this to your advantage to get ready for HTML 5, which has more types.
For example you could do:
<input type="date" ...
which would still be a regular text box, but the fact that the type is distinct, you can use javascript/css to make it more usable by adding a datepicker or something automatically.
And then, once HTML 5 actually does come around, the browser itself would be able to render a custom input widget that is specific for dates.
Another usage of this feature is type="number", which is also a valid type in HTML 5. Using javascript to monitor fields with type number would allow for immediate feedback to the user if the data they entered was not actually a number.