I'm new to Angular and trying to understand what the "x-" and "data-" prefixes mean. In the directives documentation (http://docs.angularjs.org/guide/directive) it says that these prefixes will make the directive "HTML validator compliant". What exactly does this mean?
The HTML5 spec allows for arbitrary attributes as long as they're prefixed with data- like so:
<div data-myattribute=""></div>
Whereas this would be invalid HTML5:
<div myattrbute=""></div>
For more information on data- attributes, have a look here.
As for "x-" attributes, I think you mean "x:" attributes and elements, which are specific to XHTML validation...
To expand on this, if you were to (for some reason) be using XHTML, you can define custom attributes with namespacing like so (and I'm just summarizing the gist here):
<html xmlns:x="http://sample.com/mynamespace">
<body>
<div x:whatever=""></div>
<x:mytag></x:mytag>
</body>
</html>
where the URL in xmlns is really just to prevent conflicts between like elements. Also, a DTD for the custom elements and attributes could be provided for validation purposes as a part of your DOCTYPE declaration.
*behavior in browsers is going to vary with this xmlns approach.
In summary, though: With most browsers released in the last three years, or IE8+ you're not going to have to worry about any of these things. Only in very specific situations will you really care.
From the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/single-page.html
Attribute names beginning with the two characters "x-" are reserved
for user agent use and are guaranteed to never be formally added to
the HTML language.
Also:
For markup-level features that are intended for use with the HTML syntax,
extensions should be limited to new attributes of the form "x-vendor-feature", where
vendor is a short
string that identifies the vendor responsible for the extension, and feature is the
name of the feature. New element names should not be created. Using attributes for such
extensions exclusively allows extensions from multiple vendors to co-exist on the same element,
which would not be possible with elements. Using the "x-vendor-feature" form allows
extensions to be made
without risk of conflicting with future additions to the specification.
Related
What does M stand for in the restrict AngularJS option?
From AngularJS Developer Guide - Directives documentation I see that the:
The restrict option is typically set to:
...
'C' - only matches class name
'M' - only matches comment
But in order to avoid memorizing that C is for class and M is for comment, I would like to understand why the M is used.
I did not find anything about it on the internet. My guess is that the m is the next consonant letter in the word comment after the c and since the c is already taken by comment the m is used.
This does exactly what it says it does - allows a directive to be matched to a comment.
Thus:
directive('yourDirective', function() {
return {
restrict: 'M',
template: '<span>Something in here</span>'
};
});
Can be used like this:
<!-- directive: your-directive -->
AngularJS supports comment directives but it is best not to use them.
From the Docs:
Best Practice: Prefer using directives via tag name and attributes over comment and class names. Doing so generally makes it easier to determine what directives a given element matches.
Best Practice: Comment directives were commonly used in places where the DOM API limits the ability to create directives that spanned multiple elements (e.g. inside elements). AngularJS 1.2 introduces ng-repeat-start and ng-repeat-end as a better solution to this problem. Developers are encouraged to use this over custom comment directives when possible.
For more information, see
AngularJS Developer Guide - Directive Types
AngularJS Comprehensive Directive API Reference - restrict
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
When angularJs directive is defined, we have to name it in form of 'camelCase' syntax but when we use it, we have to name it in form of 'camel-case'. Question is why this is required ?
I know that it is for avoiding naming conflicts(now/in future) but why we have to name it differently while defining and while using. Can't we define it directly in form of 'camel-case' ?
There are two reasons why it's important.
First of all, HTML attributes are not case sensitive, meaning that "someName" and "somename" is the same attribute. So the best style is to use "kebab-case" notation to separate words in attribute name. That's why we use "attribute-name" syntax for HTML attributes and tag names.
On the other hand, kebab-case names are not valid identifiers in Javascript so in order to use such names as Angular directives we would have to use verbose bracket notation. But since in Javascript world camelCase is standard de-facto for naming variables and object properties, Angular uses normalization (see source) to convert kebab-case names to camelCase, and vice versa.
Directives must have camel case names (for instance, fooBarDirective) because AngularJS converts camel case directive names to hyphen case .For instance
<foo-bar-directive>
or
< ... foo-bar-directive>
for use in HTML(which is case insensitive).
I'm currently making a bilingual Expression Engine 2.5.2 website. I'm using this technique to create the two langues, which works perfectly.
I have created a {country_code} global variable in the two index.php files which allows me to detect the current language.
Using this technique, I have no problems to get language-relative data when accessing an entry. My only concern is that I apparently have to privilege a language-specific "clean" URL.
Example entry:
{entry_id} = 123
{title} = My test article
{title_permalink} = my-test-article
{name_fr} = Mon article
{name_en} = My article
If I request http://www.example.com/index.php/en/blog/articles/my-test-article, I expect to to find, in english, "My article" using the template articles in the blog template group.
Everything is fine, but the french translation is accessible when requesting http://www.example.com/index.php/fr/blog/articles/my-test-article. The correct translation of the URL should be http://www.example.com/index.php/fr/blogue/articles/mon-article-test.
Anyone encountered a problem like this? Any solutions via extensions or modules?
I believe the Transcribe module solves this by both providing the ability to translate template group and template names, and having you create a separate entry for each language and piece of content in your site (hence, you have two separate URL titles). But that means buying into their entire methodology for a multi-lingual site.
Myself, I usually just stick to using the entry_id instead of the url_title, and live with the template names being in the primary language.
The best way I found to achieve this is by embedding templates with segment translations, duplicating template groups and duplicating channels.
In the blog/articles template:
{embed="shared/.head" segment_2_translation="blogue" segment_3_translation="articles"}
In the blogue/articles template:
{embed="shared/.head" segment_2_translation="blog" segment_3_translation="articles"}
In shared/.head template:
[...] {if lang == "fr"}English{if:else}Français{/if} [...]
And then you can create a Articles (FR) and a Articles (EN) channels, and each will have their unique URL titles. You can also add a relationship custom field for each channel to associate an entry with it's translation.
It feels messy, but it is the only way I could make it work without modules, plugins or whatnot.
Two questions:
I have been reading docs and SO posts.. and know how to do it the long way (defining each and every element and attribute myself), but all I want to do is add 2 or 3 attributes to the default whitelist.. so that I do not have to constantly find and add more elements/attributes to, e.g., HTML.AllowedElements and/or HTML.AllowedAttributes.
Specifically, now, (for internal trusted users) I need to allow javascript attributes (input from tinymce). Question #1.) Is there a way to just add an attribute (to what HTMLpurifier allows) without causing the whole default sets of allowed elements/attributes to be effectively wiped out (overwritten by ONLY what is explicitly written in HTML.AllowedElements or HTML.AllowedAttributes)?
For what I need right now (the javascript attributes), I got excited when I saw in this thread:
Whitelist Forms in HTML Purifier Configuration
...where Edward Z. Yang says, "... [$config->set('HTML.Trusted', true);] allows JavaScript."
...but even after setting this: $config->set('HTML.Trusted', true);, HTMLpurifier 4.4.0 is still stripping e.g. any input onclick="dostuff();" attribute. Why? Question #2.) Is there a quick way to add just the javascript attributes to the allowed list?
You're losing onclick because HTML Purifier doesn't know about that attribute, and if HTML Purifier passed everything through when you turned on %HTML.Trusted you might as well just not use HTML Purifier at all.
HTML Purifier has attribute collections for just this case; 'Common' is probably the right one to insert them into.
But... why? The real name of %HTML.Trusted really should be %HTML.UnsafeMakeMyApplicationVulnerable
HTMLPurifier does not support onClick and similar java script related attributes to any HTML element as a default behaviour.So if you wish to allow such attribute any way, you may add such attribute to specific element in following way.
$config = HTMLPurifier_Config::createDefault();
$def = $config->maybeGetRawHTMLDefinition()
$def->addAttribute('a', 'onclick', 'Text');
But be careful, this may lead to xss attack as you are allowing any java script code to be there in that attribute.