How can I force dom-elements depending on a binding (like the value-attribute of an input-element) to rerender even if the value of the binding has not changed.
Binding itself does not expose such a method and I was not able to use one of the other classes like Map in my code...
Interesting! Some one just asked a reverse question to avoid re-rendering a DOM element at Toomany DOM updates .
So, the answer to your question is reverse committing the PR mentioned in the other question.
Related
I am building simple crud for an entity. Initial state is read on particular entity(key) using view>form.bindElement('/entity(key)').
when I click on new button I clear the form and when the cancel button is clicked during the new/create process(without performing the save), how to go back to the previous entity. Is there some place ui5 stores, the previous entity or should I have some variable and assign it to the controller.previousEntity = oldsPath?
what are the different members in the oModel,it start with
a(aBindings)
b(bUseBatch)
m(mContexts)
o(oHeaders)
p(pCallAsync)
s(sPathUrl).
Is there a naming convention in these?
From what I can see, there are following things you need to notice and work upon.
Its generally not a good idea if you use the same form to display and to create/update also. A simpler approach would be to
use a new popover to show the form for create and in that case, the view binding would not be changed when you cancel the operation.
However, if you still want to use the same form, yes you would have to bind the view/form again on cancel operation. You can have a variable declared in the Component.js to store the path for you. In UI5, the model captures the current state to ensure the back the binding concept by default.
You can check all properties and their definitions here: oData Model
Yes, there is a naming convention followed here.
a - Array, s-String, b- Boolean etc.
Read more about Hungarian notations for naming conventions
The previous entity is still there in the cache (ODataModel.oData), but you'll need to re-bind it. For that purpose, as you have written, you'll need to store the path to the entity yourself. Once you bind the control, I don't think the previous binding context is stored somewhere (why should it).
I would like to append a Binding node to another Binding node without re-rendering the parent node.
Is there a specific way how Binding.scala would handle this?
Bindings can be nested and composed, so in general it's not something you need to think about. A Binding[T] represents an object that is dynamically bound and will be recomputed when any upstream Binding's value changes.
Your question is a bit ambiguous so you may want to clarify or add a code example, but there is nothing extra you need to do to accomplish your goal. Look at the examples and also this section of the README:
https://github.com/ThoughtWorksInc/Binding.scala/blob/11.0.x/README.md#precise-data-binding
Also, I made a quick example of what I'm talking about here:
https://scalafiddle.io/sf/XZgtwHM/1
If you open up your browser console, you'll see that the method that renders out the parent node is only called the first time, but if you click the button more child elements will be appended without the parent node being affected. Inspect the HTML and pay attention to the id of the parent div, it is set up to increment the ID each time it gets rendered, and the id remains as "parent_1" the whole time.
The link [https://ccamel.github.io/playground-binding.scala/index.html#playground-binding.scala/home]
has few demos of binding.scala
I have used DomListner extension in chrome to understand the dom events.
I found for each interaction there are hundreds of DOM events fired.
For example one click on calculator button results in 114 events.
It this a performance issue ?
Does binding.scala library need performance improvements ?
Does the code written using binding.scala need optimization ?
It's the expected behavior, because the DEMO that you mentioned recreated anchor elements, explicitly.
According to the Scaladoc for bind method:
Each time the value changes, in the current #dom method, all code after the current bind expression will be re-evaluated
As a result, the calc.bind call at here forces recreating the anchor element.
I created a pull request to change the class attribute instead, by avoiding the calc.bind call before XHTML literals.
In the 1.5.2.3 Defining a Binding Path section of OpenUI5 demokit:
A context exists either for each entry of the aggregation in case of aggregation binding or can be set explicitly for a control by using the setBindingContext method.
In the 1.5.3.3 Element Binding section of OpenUI5 demokit:
Element binding allows to bind elements to a specific object in the model data, which will create a binding context and allow relative binding within the control and all of its children.
It seems to me that the two techniques actually do the same thing. They both create a binding context for a control so that bindings of the containing controls will resolve relatively to it. But what's the difference between them? In what scenario will either of them come into play?
The setBindingContext doesn't work in the following code:https://jsbin.com/bigope/edit?html,output
However, if I change oPanel.setBindingContext("/nameinfo"); to oPanel.bindElement("/nameinfo");, it works, why?
setBindingContext requires you to pass a Context like this:
oPanel.setBindingContext(new sap.ui.model.Context(oModel, "/nameinfo"));
The difference between those two is conceptual.
The Binding Context is used as a parent context for all bindings (for that model) in that Control or its children. It only holds a reference to the used model, (a part of) the path and optional another parent context. It is used when creating relative bindings.
The bindElement method on the other hand behaves like every other bind* method.
It creates a binding (in this case, a ContextBinding) which allows change events, data binding, etc.
Additionally the created ContextBinding also serves as a BindingContext for other bindings, just like a Context added with setBindingContext would do.
Not confusing at all, right ;)?
Reading the code for ManagedObject might help you to understand the internals better. (bindObject = bindElement)
here's my problem, I'm using mootools' Drag&Drop functionalities, it works great but i can't find a way to add new droppable element on the fly since the droppable element are defined when the draggables are.
Their is a method makedraggable that you can use to add draggable element but it has no equivalent for the droppables.
With jQuery, you set the draggable elements on one side and the droppable on the other, so you can do pretty much what you want.
Do you know a way to solve my problem?
in theory, you should be able to push elements to the instance.droppables collection.
var foo = new Drag.Move({
droppables: document.getElements('div.dropHere'),
...
});
foo.droppables.push(document.id('newDropHere'));
// or...
foo.droppables.include(element); // etc. all array/Elements methods.
read https://github.com/mootools/mootools-more/blob/master/Source/Drag/Drag.Move.js
if you want actual help, build an example on tinker.io or jsfiddle.net. if memory serves, this has been asked here before and there had to be some extra work around parsing possible droppables in addition to adding to the Collection.