I have a form in a razor page where im implementing clientside validation using jquery, jquery unobtrusive and jquery validation alongside dataannotaions to validate the model.
Using strongly typed textboxes i get the data-val attributes that i need for displaying errors using ValidationMessage() method.
HOWEVER when i use the loosely typed textbox the data-val attributes does not get generated, why is this?
it is important that it works for Html.Textbox() since im using a more complex data structure and need to define specifik names for each element in the list.
loosly typed textbox and validationMessage:
Generated html:
Strongly typed textbox and validationMessage:
Generated html:
we can clearly see the data-val attributes here
The name field is built up like this (where key is a guid uniqe to each item in the list):
how come the data-val attributes don't appear with loosly typed textboxes?
I think i know the answer, since it is strongly typed we have information about the dataannotation in the model, whereas the loosley type just generates html from a name.
Related
I have an external blazor component with 2 attributes like below. I am resolving through a function by passing the value of Href attribute.
<ComponentLink Href="bookings" Active=#GetCurrentLink("bookings")>
1my question is there any way to reference or bind the value of attribute value directly from another attribute without passing through a variable.
Basically something like
<ComponentLink Href="bookings" Active=#GetCurrentLink(#Href)>
I am asking this because it is within link list for a navigation and i dont want to create a fiel or property for each Href element. I can fix it on the ComponentLink source code possibly but I don't have source code access as it is in nuget package.
I have tried using #ref but It also doesnt help as intented.
There is no easy way to achieve this.
You can look at the component definition in the same way as the class constructors. You will have the same problem when you want to pass the same value there.
The best option, in this case, is to extract the text in the variable and reuse it.
You can also define your links in your C# code as an array and just enumerate the links to render the ComponentLink components dynamically.
Here is an example of this approach: https://blazorrepl.telerik.com/wmFYwAvG39LqBZFb06
The option with the #ref is not working, because the #ref value is populated once the component is rendered and typically, you will need to evaluate the Active value before that.
A site I came across uses input type="private" for its password Form field. However, I searched online and it seems that "private" is not one of the defined types (https://www.w3schools.com/html/html_form_input_types.asp)? What does it do and where can I search for more details on this?
As you said, private is not one of the HTML input types. (MDN reference)
Even semantically, the input type 'private' does not make any sense. Input element with unknow type is rendered as text type by default. So here private is just some gibberish for the render.
I guess the site you came across might be doing for any specific use-case - CSS selector like input[type="private"] or with JavaScript - which is not the way to do. As this not standard, it should not be used.
type=private simply isn't one of the default values that the browser would recognize.
However, you're free to give it any type you want, you could give it a type="peanutbutter".
Doesn't matter, cause what matters is: now you can call that input type with jquery or something by doing input[type=peanutbutter] to select all inputfields with that specific type using javascript, jquery or css.
My guess is that type=private doesn't exist, but it's simply something used by that company to manipulate the inputfields.
To set string #Input() properties of the component, we can use two type of syntax:
<my-component caption="Hello there" type="primary" someThing="text value"></my-component>
OR:
<my-component [caption]="'Hello there'" [type]="'primary'" [someThing]="'text value'"></my-component>
I'm fully aware of the differences between those two types of bindings. The question is: If I have bunch of string #Input() properties that I want to set statically, can I use simple attribute binding syntax (first example) than more "meaty" property binding syntax (second example)?
What is the recommendation, and why? I.e. what are the trade-offs and is it preferable to use property-binding always, even for setting static string inputs?
Here are the few drawbacks I can think of:
Attribute bindings are actually applied as HTML attributes, and e.g.
user can see/alter them via browser's dev tools easily. Property
bindings are not part of the markup.
Attribute bindings might collide
with actual HTML attribute names (unless you prefix them with data-
which defeats the whole purpose of simplicity). Actual example that
already bit me is title attribute.
There is no intellisense in markup for attribute bindings with Angular Language Service.
But the major advantage is the simplicity. In the example above, you would agree that the first form is more elegant. In my projects it seems that big number of properties are constant (one-time-set) string properties, and the syntax makes actual difference in readability.
So... Is it a bad practice to use attribute-binding syntax for custom (non-HTML) string properties? (Given the fact that I'm aware/ok with above listed few limitations)
These are a couple of things I like to add:
Attributes are just plain static fields.
There is a fine line when attributes become properties.
Simplicity is not the goal here, modularity and reuse-ability is.
Property binding give you more control in your component and you can use a component in any like any data-driven or static scenario.
One component build right with property binding can be used in 20 different projects.
But if you got no such requirement then you can use attributes. They are fine.
I will not say which one is better, both have their use cases but overall property bindings are lot more powerful and flexible.
And last thing I like to mention for all readers:
In front-end development any one can modify the code. We use
validations just to provide a smooth user experience. Other than that
any one can get the code or alter HTML if they want to, that's why we
use server side validations. Angular pipe line is complex but
hack-able. A user can wrap a JSON object and send it to server
bypassing all our validations. So for all readers who are new front-end
devs, we don't bother too much about security, we try our best to give
a good user experience.
I have a doubt about good practices writing HTML with Javascript.
I've came up with an idea (probably not the first, but couldn't find a clear reference about that) to mark some elements as candidates to load some data when it's available (after some user interaction). Let me exemplify:
Suppose I have a request that returns the following:
GET /animals/dog
{
name: "Gutemberg",
race: "doberman",
age: "2y"
}
The code I wrote binds fields in the response to elements that are candidates to load such value.
For example: With the request above, I could use the following tags:
<input name="dog-name-field" data-load-dog-name type="text"/>
<input name="dog-age-hid" data-load-dog-age type="hidden"/>
Each tag would receive the property value because it's marked as a candidate to do so - dog-name-field will have a value of "Gutemberg" when everything executes . That will happen everytime the request is reloaded. For now, I just get the data type I've searched ("dog"), concat it with the property "name/age" to form the attribute data-load-type-property and set a value to everyone that has such attribute.
I have a feeling that attributes are not meant to be used just like that, but I'm not aware of any real downsides to that. As I could not find it for the lack of a clear name to this approach, I'd like some guidance.
Is there a name for such technique? Is it a bad practice? If so, why?
PS:
To comply with SO good practices, I'd like the answers to be reference-guided and not based solely on opinion whenever possible. If no reference is provided, please, let us have a solid, well described example.
I have a feeling that attributes are not meant to be used just like that
Let's see what custom data attributes are meant to be used for:
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements. These attributes are not intended for use by
software that is independent of the site that uses the attributes.
(from w3.org)
So whether using data-attributes is "appropriate" in your case depends on your needs: if the DOM API doesn't provide better attributes to do that then it's appropriate.
If your need is just to select some element to change the textContent then you have two more appropriate/simpler options:
1) Using the id attribute if your elements are going to be unique in the document
The id global attribute defines a unique identifier (ID) which must be
unique in the whole document. Its purpose is to identify the element
when linking (using a fragment identifier), scripting, or styling
(with CSS).
(from id on MDN)
2) Using the class attribute if your elements are going to be used in multiple instances in the document
The class global attribute is a space-separated list of the classes of
the element. Classes allows CSS and Javascript to select and access
specific elements via the class selectors or functions like the DOM
method document.getElementsByClassName.
(from class on MDN)
As #Supr says in his answer, what you are doing is a very simple implementation of data-binding. data-binding can involve a lot more complexity than what you are doing at the moment; for example you may want to:
keep in sync your UI with a Javascript object which represent your business model instead of directly injecting data coming from an Ajax call,
update other attributes (value, style) and not only innerHTML or textContent,
have your business model updated in reaction to changes on the UI (two way data binding)
To implement all these features, simple id and class selectors are not sufficient, and this is why frameworks which implement data-binding, like KnockoutJS or AngularJS, use the more flexible data-* attributes instead (AngularJS is actually using its own ng-* attributes, but allows to use the alternative data-ng-* syntax for using HTML validation tools).
Data attributes allow to describe much more complex bindings:
<input data-bind="visible: editing, value: name, hasFocus: editing" />
Check KnockoutJS documentation for the meaning of the above code, it is not relevant to this example but just imagine describing that with classes or ids, it wouldn't be very convenient.
TL;DR
If you don't plan to implement more complex features you might want to use class and id instead.
This is called binding. Sometimes data binding and sometimes template binding.
Various frameworks provide mechanisms for this, though the syntax varies.
AngularJS example:
<input ng-model="dog.name" />
Knockout example:
<input data-bind="textInput: dog.name" />
React example:
<input value={this.state.dog.name} />
These are all quite popular frameworks/libraries, so I think it's safe to say it is not considered bad practice. The main difference from your approach is that they use the value of the attribute to specify the reference into the model (i.e. the "dog.name" part of your attributes), while you are putting the reference in the attribute name. In practice this is mostly a matter of style. Separating the reference from the "marker" (i.e. "data-load") is perhaps a bit more readable.
I've noticed a lot of websites with form(s) containing input fields whose "name" attribute is specified even if it isn't used for styling or scripting purpose!
Moreover, according to the official document about the form in HTML document ...
name = cdata [CI] This attribute names
the element so that it may be referred
to from style sheets or scripts. Note.
This attribute has been included for
backwards compatibility. Applications
should use the id attribute to
identify elements.
So, my question is: should this attribute used only for styling and scripting purposes?
Thanks in advance!
EDIT: In particular, could be avoided the use of this attribute with input fields of "text" type (when there aren't no styling or scripting purposes)?
EDIT 2: So, you have almost confirmed what I had thought about: the "name" attribute will be deprecated in further HTML specifications/standards!!!??? It is still "alive" only for backwards compatibility ... in some cases can be avoided but there are still some cases (such as the radio button) where it is necessary!
I think you'll find almost every site will have inputs with the name attribute. I don't see it going away anytime soon.
The name attribute specifies a name
for an input element.
The name attribute is used to identify
form data after it has been submitted
to the server, or to reference form
data using JavaScript on the client
side.
Note: Only form elements with a name
attribute will have their values
passed when submitting a form.
source
The name attribute is the notation to reference specific elements within the scope of a webpage through non-DOM Javascript:
document.forms['your_form'].elements['aa']
The id attribute for the element needs to be set with the same value for the following to work:
document.getElementById('aa')
My understanding is that when Netscape created Javascript, it used the name attribute. The HTML spec however decided to go with id, but kept name for backwards compatibility. IME, using the name attribute was required for Internet Explorer 6 support because the javascript engine in IE wouldn't read the id attribute - only the name though both were defined.
...could be avoided the use of this attribute with input fields of "text" type (when there aren't no styling or scripting purposes)?
If you don't have any javascript attached to the text fields, yes - they would be unnecessary.
There are differences between id and name attributes. An id is applicable to any element in the HTML document while a name is relevant for input fields only. An id is required by standard to be unique in a page (though not necessarily followed in all web pages). Different elements may have same name though. One particular case comes into mind is the radio button. All radio buttons should have the same name and the value of the one selected would be given back to the form. So you can see that name still has significance in HTML form processing.
I have seen in automatic HTML form generation systems (like zope.formlib), that id and name attributes both are automatically generated for different types of input widgets. Such automatic form generation systems take proper care of all the nuances associated with differences in id and name attributes. They also do things like generating a hidden input element for each checkbox element. So wherever possible, I try to use some sort of automatic HTML form generation mechanism and let it take care of the issues involved.
This is an old question, but it's worth noting that many modern JS frameworks rely on the name attribute. In particular, jQuery's serialize function:
For a form element's value to be included in the serialized string, the element must have a name attribute.
If anything, name seems to be making a comeback.
It's also worth noting that the name attribute is useful because it has slightly more "scope" than id. id must be unique within a page, but the same name can be used multiple times. This makes it useful when you have multiple forms on the same page, or when you want to reference a group of checkboxes, etc.
IIRC older browsers use name in place of ID, that's why it's normally included.
Your reference to HTML 4 is way out of date. Here's WHATWG's discussion of name - https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#naming-form-controls:-the-name-attribute
name should not be used for scripting or styling. That is what id is for as you have said.
But name is not obsolete and I see no prospect that it might be removed from HTML. Its purpose is specifically to submit data to a server.
id should be unique for your HTML document to be well formed. name might not be. You might have a set of three radio buttons, let's say "Small", "Medium" and "Large". You could give them three unique values for their id attributes, so if your user interacts with other elements you could change the selected radio button in script. But when the form is submitted, you want only one value to be submitted, so you give all three radio buttons the name value for name.
<input type="radio" id="size-small" name="size">Small</input>
<input type="radio" id="size-medium" name="size">Medium</input>
<input type="radio" id="size-large" name="size">Large</input>