I'm testing OmniFaces importConstant functionality and successfully display a constant on a page like this:
#{Config.SOME_CONSTANT} (writes 4 to the page)
If I try to do this in a f:viewAction however, it doesn't work:
<f:viewAction action="#{bean.someMethod(Config.SOME_CONSTANT)}" />
It resolves to zero in the method.
What am I doing wrong?
A viewAction is and called right after metadata parsing (see this article) and before the view is even rendered.
I'm not quite sure what the "EL Scope" referred to in the documentation is, but it appears to be render time only, ie only until after your viewAction is called.
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?
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 need reject for sap.m.Input control any input except integer values. So in input may be inputted only 0-9, without any sign symbol(+-) or any decimal separators. I Can't find good solution. View declared in XML format, and preferable way is just change this XML with additional parameters, if it possible.
Possible solutions:
The first one - write custom formatter.
The second one - try to find some standard solution with types. I found internal data types and they settings, but it seems that they not working well.
A custom formatter won't help you in this case as its only used oneway (model->view).
But data types are your friend here. I would suggest sap.ui.model.type.Integer with a minimum constraint of 0.
<Input value="{path: '/value', type: 'sap.ui.model.type.Integer', constraints:{minimum:0}}" />
However this does have two prerequisites:
You need to enable complex databinding. This can be done in the bootstrap tag in index.html with the data-sap-ui-compatVersion attribute. Version 1.26 is needed at least. You can use the value edge to specify the newest version:
<script src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js"
id="sap-ui-bootstrap"
data-sap-ui-theme="sap_bluecrystal"
data-sap-ui-libs="sap.m"
data-sap-ui-compatVersion="edge">
Alternatively you can use data-sap-ui-bindingSyntax="complex".
If the user enters invalid data the datatype throws a ValidationException. The error will be silently ignored but the model won't be updated. To get some feedback for the user you can register the control or the whole view at the MessageManager:
sap.ui.getCore().getMessageManager().registerObject(this.getView(), true);
You can also enable handleValidation in the Component or when instantiating the component.
Example on JSBin.
Regex is your friend here.
Here is a pretty simple jsbin I re-used from someone validating text only and modified the regex to accept numbers only.
You could wire the validation into the change event so it would fire and set the state to error if text entered.
Let us know how this works out.
Cheers,
Nigel
How to debug EL in the JSF page? I'd like to watch variable values, function calls an so on. The best solution would be an eclipse plugin, but any other possibility is better than guessing "Why this expression failed to render correctly?".
Closest what you can get in JSF/Facelets is placing an <ui:debug /> somewhere in the view:
<ui:debug />
Pressing CtrlShiftD should then show a popup window with debug information about the component tree and all available request parameters and request/view/flash/session/application scoped variables. It's basically a representation of the content of all those maps.
The hotkey is by the way configureable by hotkey attribute so that you can choose another whenever it clashes with browser default hotkeys, as it would do in Firefox; CtrlShiftD would by default show the Add bookmarks dialogue. Here's how you could make it to listen on CtrlShiftX instead:
<ui:debug hotkey="x" />
You'd usually also like to hide it in non-development stage, so add a rendered condition like that:
<ui:debug hotkey="x" rendered="#{facesContext.application.projectStage == 'Development'}" />
In the shown debug information, the information provided about scoped variables isn't that great as you would expect. It only shows the Object#toString() outcome of all scoped variables which defaults to com.example.Bean#hashcode. You can't explore their properties and the values of their properties directly like as you could do in debug view of Eclipse's debugger. You'd need to implement toString() on the class accordingly so that as much as possible relevant information is returned (if necessary, you can even let Eclipse autogenerate it by rightclick source code > Source > Generate toString()):
#Override
public String toString() {
return String.format("Bean[prop1=%s,prop2=%s,prop3=%s]", prop1, prop2, prop3);
}
As to method calls, just put a breakpoint on the Java source code the usual way. Eclipse will kick in there as well when EL calls the method. If it's a managed bean, you'll also just see its properties in the Eclipse debugger.
If you are really having problems then if you can get the source for the EL implementation (easy enough for the RI) then you can use Eclipse to set breakpoints in the EL implementation methods. You need to get an understanding of how the EL code works, but it isn't that complicated. Not for the very faint hearted though.
Another possibility would be to create and evaluate the EL programatically. There are examples of how to do this around. You can then use the debugger to fiddle around with what the expression is and what the result is until you've worked out where your problem lies.
I have a problem with my firefox extension
I have a XUL popup panel with a hbox for the tag cloud, and a JS code to add divs to this hbox:
<hbox id="tag_base" ondblclick="alert('done')"/>
JS:
var root = document.getElementById('tag_base');
var tag = document.createElement('div');
tag.textContent = 'test';
root.appendChild(tag);
var rect = tag.getBoundingClientRect()
alert(rect.top)
I need to get the dimensions of each added div, however, getBoundingClientRect simply refuses to work.
If I remove alerts, it's always zero.
With alerts the story is different:
The first time the alert is called it returns zero, although the div appears on the screen.
Any subsequent alerts return the correct coordinates.
If I set a breakpoint in Chromebug, everything is reported correctly.
If I do not interupt the execution in any way, and run a loop, only zeroes got returned.
This has got me quite confused.
Calling "boxObject" produces the same results, while "getClientRects[0]" is undefined on the first call.
Any hints on what might be causing this will be greatly appreciated.
Note :
Caution, if you use getBoundingClientRect with an element which has display:none then it will return 0, anywhere in the dom.
Although I can't find any documentation on this seemingly fundamental issue, the problem you noticed is most likely because the layout (aka "reflow") process has not yet run by the moment you ask for the coordinates.
The layout/reflow process takes the page's DOM with any styles the page has and determines the positions and dimensions of the elements and other portions of the page (you could try to read Notes on HTML reflow, although it's not targeted at web developers and probably is a bit outdated).
This reflow process doesn't run synchronously after any change to the DOM, otherwise code like
elt.style.top = "5px";
elt.style.left = "15px";
would update the layout twice, which is inefficient.
On the other hand, asking for elements position/dimension (at least via .offsetTop) is supposed to force layout to return the correct information. This doesn't happen in your case for some reason and I'm not sure why.
Please create a simple testcase demonstrating the problem and file a bug in bugzilla.mozilla.org (CC me - ***********#gmail.com).
My guess is that this is related to XUL layout, which is less robust than HTML; you could try creating the cloud in an HTML doc in an iframe or at least in a <description> using createElementNS to create real HTML elements instead of xul:div you're creating with your current code.
Be sure the DOM is ready. In my case, even when using the getBoundingClientRect function on click events. The binding of the events needed to happen when the DOM is ready.