Out of curiosity, what's the reason behind using {block:Title} instead of just {Title}:
{block:Title}
{Title}
{/block:Title}
I do it because Tumblr tells me to, but was wondering if there was a good reason for it. If it's to run conditionally (i.e. to show title when there is one), wouldn't {Title} alone suffice since it's a variable, as it displays nothing when there is no title?
What's the blocking point?
If it's to run conditionally (i.e. to show title when there is one), wouldn't {Title} alone suffice since it's a variable (i.e. it displays nothing when there is no title)?
Whilst strictly true, as no string is rendered if no title exists, markup will still be rendered. For example, lets pretend the title is empty.
Markup
<h2>{Title}</h2>
Output
<h2></h2>
This would be undesired. However, combine title with {block:Title}.
Markup
{block:Title}
<h2>{Title}</h2>
{/block:Title}
Output
<!--nothing to see-->
tl;dr - Always use the blocks, to stop empty elements being created.
Related
This feels like it should be really simple, but I for the life of me can't figure it out. I have a StatusIndicator in my application and wish to give it a non-numeric label based on its value. I believe that this should be possible, because the fiori guidelines for status indicators have example screenshots showing this behaviour on the bottom of the page (ok, granted, they're still all numeric, but not labelled with percentages).
Referring to the API Documentation shows that StatusIndicator possesses an aggregation "label" which takes a Text-control. So I tried to use that (XMLView excerpt, link to plunkr below):
<si:StatusIndicator value="70" showLabel="true">
<si:ShapeGroup>
<si:Circle cx="50" cy="50" r="20" />
</si:ShapeGroup>
<si:propertyThresholds>
<si:PropertyThreshold fillColor="Good" toValue="100"/>
<si:PropertyThreshold fillColor="Error" toValue="50"/>
</si:propertyThresholds>
<si:label>
<Text text="Hi there"/>
</si:label>
</si:StatusIndicator>
(Example in plunkr)
However, this doesn't work. From my application I know the Label is used in some way (a formatter-function for the text is called), but the displayed label remains "70%" in the above case, instead of the expected "Hi there". Using a numeric value here does not work either, so it appears not to be due to that.
Am I misunderstanding something here? Unfortunately I was not able to find anything on this, and the API documentation on the label aggregation is rather sparse to put it mildly.
Final notes:
I already tried using 'showLabel="false"' (thinking, maybe it only uses the custom label if the default is turned off), but that just removes the label entirely (as expected).
I'm sure I could make a custom control for this, but would prefer not to, if I don't have to.
tldr: Why is the label-aggregation for a StatusIndicator control (seemingly?) ignored, and how can I add a custom label to the StatusIndicator that is based on, but not equal to, the value property?
In Chrome DevTools, the element tab shows the constructed DOM and I can click on elements in the DOM which also highlights the element on the page. Image of both versions shown in DevTools
If the DOM shows:
<input class="gLFyf">
Then the page highlight will show:
input.gLFyF
I realise these are two ways of writing the same thing, I also realise the former is HTML style and the latter follows CSS conventions. However, I lack the vocabulary to properly refer to either.
What do I call each format?
Eg. would it make sense to refer to <input class="gLFyf"> as HTML syntax and input.gLFyF as CSS syntax? Is there a more widely accepted way to differentiate and name them?
gLFyf is the name of the class which is an attribute that can be referred to in the stylesheet to match styles with elements of that class on the page.
A class leads with a period (.) - whereas an ID would lead with a hash (#).
So .gLFyf is a class.
And #gLFyf would be an ID.
It is a class, whether viewing HTML markup or the DOM inspector. They both refer to the same thing as you already state.
This may be of some use/reference.
This is the weirdest issue I've ever faced in a long time. I have a URL that is authored inside a multifield. The URL has an underscore eg. http://example.net/_pinkPanther_is_pink it is currently inside ${item.link}
When I do Click <br> ${item.link} and inspect, it renders as
Click
<br> http://example.net/_pinkPanther_is_pink
If you notice both values are coming from the same variable in Sightly still when the link is used inside href of anchor tag there is double underscore added by God know who after example.net/
Does anybody have a clue as to what on earth is going on ?
That's caused by the display context aware XSS protection. Sightly/HTL automatically detects the display context of a HTL expression, using its location within the structure of the HTML page to detect it.
For example, if the expression appears in a place that would produce a text once rendered, then it is said to be in a text context. If it is found within the value of an attribute, then it is said to be in an attribute context, and so forth. More about contexts in the htl specification page.
In your example, the implicit context inside the href attribute is uri while in the later case is text.
In order to overwrite this behaviour, you may explicitly set the context like href="${item.link # context='text'}.
I've tried all the HTL context parameters (even 'unsafe'). When I inspect the input, I can see the value intact, but you can't see the value pre-populated in the field. I tried different types of values, different contexts, and different types of input fields. [AEM 6.2]
<input type="email" name="senderEmail" value="${userProfile.email # context='text'}"/>
If the value is rendered in page source and also visible in browser inspector, could it be that it's hidden by some weird CSS? Something like color:transparent
There are many possible causes. I'll pitch in one, to help get you thinking. Is userProfile available via the use api?
I've made this mistake before:
<div data-sly-use.bean="com.beans.Bean">
${bean.value}
</div>
// ... other code
${bean.value}
The "Bean" isn't available later, outside it's host element.
If I understand your question correctly this isn't actually about HTL, but rather about the HTML input element itself. You have an input element with a value attribute set, yet that value is not displaying in the box. If that's correct, then I'd recommend doing some investigation around HTML input value not displaying when set, rather than sightly context issues.
Some possible answer would include css styles hiding the input text or javascript clearing out the values after page load. There are certainly more potential causes, but we'd need to know more about your page to provide a better answer.
To do some of your investigation you can try loading a component with only that input in it and see if that works, that would eliminate any css or js executing elsewhere on the page.
I'm working on a site in EPiServer, and whenever I create a page property with the type set to "XHTML string" (which uses the WYSIWYG content editor in Edit mode), it wraps all content in <p> tags.
Is there any way to prevent this from happening? I can't remove the paragraph margins universally through my CSS (e.g. p {margin: 0 !important;}) since I do need the margins for actual paragraphs of text. I've even tried going to the HTML source view in the editor and manually deleting the <p> tags that it generates, but it immediately adds them back in when I save!
It doesn't happen when the property type is either a long or short string, but that's not always an option since the content might contain images, dynamic controls, etc.
This is becoming a real nuisance since it's very hard to achieve the layout I need when basically every element on the page has extra margins applied to it.
As Johan is saying, they are there for a reason - see more info here. That being said, it's not impossible to remove them. It can be done in one of two ways (taken from world.episerver.com:
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
myEditor.InitOptions["force_p_newlines"] = "false";
}
or
<script type="text/javascript">
tinyMCE.init({
force_p_newlines: false
});
</script>
You can add your own custom TinyMCE-config that removes P-elements or strip them out using regular expressions either when saving the page or when rendering the property/page.
I think it's a bad idea though. P-elements are what the editors generate the most and in most cases their content is also semantically correct. Better to wrap your property in a div with a class and adjust margins using CSS like you mention.
If you're using a version of EPiServer with TinyMCE editors, you can insert <br /> elements instead of <p> elements if you type shift-enter instead of enter. This should eliminate your margin problems.
More info at the link below:
http://www.tinymce.com/wiki.php/TinyMCE_FAQ#TinyMCE_produce_P_elements_on_enter.2Freturn_instead_of_BR_elements.3F
EDIT: My comment below answers his question better.
I discovered that while I can't remove the <p> tags from the source view (because it adds them back in automatically), if I replace them with <div> tags, it'll leave things alone. It does mean that I've got an extra <div> wrapping some elements that I don't really need, but at least a <div> doesn't add margins like a <p> does, so...good enough!