I am using a lightning-record-edit-form as shown below
<lightning-record-edit-form object-api-name="Client_Intake__c">
<lightning-input-field name="Id" field-name="Hub_Spoke_Account__c" style="width: 650px;" onchange={handleAccountFieldChange}></lightning-input-field>
</lightning-record-edit-form>
According to https://www.lightningdesignsystem.com/components/form-element/ , the lightning-input-field control value is supposed to be required only if we add the required attribute to it. Even though I do not have the required attribute set on the lightning-input-field , it is still being displayed as a required field.
How can I fix this?
A bit late to the party here, but:
Even though you haven't specified the field as required on the lightning-input-field, the field is still required in Setup, hence why it is showing as required here. This is a feature (or limitation if you will) of the lightning-record-edit form. The only solution really is to set the field as not required in Setup -> Object Manager, and to only make it required on the relevant page layouts where applicable.
Also, you will get answers a lot faster on salesforce.stackexchange.com
Related
I have all required permissions to do whatever I want. This is our bug item template. We have a pre-existing Boolean item we've used for years now (To be Triaged - pictured below). It used to be defaulting to false, I want to default to true.
Is the only way / correct way to do this via a custom rule on create? Seems odd. Other text based fields for example allow you to specify required (this is greyed out, presumably because it's a bool?) and subsequently a default. This does not. Seems to require an explicit "rule" be created.
I could not find a way to do this without a custom rule. This rule worked for me:
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?
I'm working with Symfony2 to set up a form, where a Shelf-Entity can be edited.
A shelf contains a collection of Readable-Entities (e.g. Book, Magazine, etc. - all inherit from Readable).
The user has the possibility to add more Readable-Entities (the form is extended via JavaScript) and from a dropdown he can select the type of Readable he wants to add. Depending on the selected dropdown-value, different form fields are rendered. So far so good.
Now, when the form is submitted to the server, depending on the Readable-Type the user selected in the form, a different entity-type should be instantiated.
If I don't do anything, Symfony just instantiates the base class Readable (and not Book, Magazine, etc.).
How can I tell Symfony to instantiate the correct type of Readable depending on the selected value from the dropdown?
I tried with FormEvent-Listeners, but:
in PRE_SUBMIT I only get an array containing the "raw" form data with $event->getData(), i.e. no entities have been instatiated so far. However, at this stage, I still have access to value of the dropdown.
in SUBMIT the form data was already assigned to the appropriate entities. Also the new Readable was already instatiated with the base Readable-Class. But now, I cannot access anymore the value from the dropdown.
What is the correct way to do this?
EDIT
Added a minimal Code-Example for the Shelf FormType:
https://gist.github.com/anonymous/401495b701982adafb96
Code for infinite_form_polycollection:
https://gist.github.com/anonymous/b5f0ed10ca9c52177f01
Have you tried looking at this part of the doc? As "embedding a form" seems to fit your needs.
It seems that there was something wrong with the PHP-Files of the PolyCollection in the vendor-directory, because after removing everything related to the Infinite Form Bundle from the vendor-dir and reinstalling it with composer, everything is working now. But thanks for your efforts YoannCh
What's the correct XPath syntax to check if an option element is currently selected, or just to get the selected option element from a select element, on an open page with which the user, and JavaScript, may have interacted? Is this even possible with XPath, or does it lack the ability to look at DOM properties?
I can't find any documentation on this, and have (speculatively) tried:
//option[#selected=true]
//option[#selected="selected"]
//option[#selected]
but none of these work; they simply don't match any elements.
(In case it matters, I've tried this both using the $x function in the Chrome developer console, and using the find_elements_by_xpath method in Selenium for Python.)
Short answer: it's not possible.
Longer answer: XPath can look at HTML attributes, but it can't look at DOM properties. Selecting an <option> element in a <select> changes the selected property of the <option> to true, and also changes the value property of its parent <select> element, but it doesn't affect the attributes of either, so it is invisible to XPath.
To find <option> elements that have the selected attribute set, which is often how a page author might determine which option is initially selected, you can use //option[#selected]. But this does not find the currently selected <option>; changes that the user makes to the selection are invisible to XPath. There's no guarantee it will even find the initially selected option, since it's possible that the page author didn't put the selected attribute on any elements and either let the browser select the first option by default or had some JavaScript select the initial option via the selected property.
The multiple other answers here claiming that a selector like //option[#selected] can detect selection changes made by the user after the page loads are simply completely wrong.
Of course, if you're able to use CSS selectors instead of XPath selectors, then option:checked will do the job.
The problem could be the " (double quotes).
//select/option[#selected='selected'] - Will match the selected option, i am using this successfully.
//select/option[#selected='selected' and #value='specific value'] - Will only match the selected option if it has a 'specific value', i'm also using this.
If you are still having trouble, it could be an entirely different problem, perhaps there is no option node. I hope this helps.
I think we can use a knowledge from #Mark's answer and account that. Let's just find a node which HAS desired attribute:
tree.xpath('//select/option[#selected]/text()')[0].strip()
I tried "//option[#selected=''] and it has worked for me.
it is able to highlight the selected option within Page objects model.
I would try //option[#selected='true']
i.e. driver.findElements(By.xpath("//option[#selected='true']")).getText();
I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element