In Dash, by Plotly helping section in Callbacks https://dash.plotly.com/interactive-graphing it is stated that:
Dash components are described declaratively by a set of attributes. All of these attributes can be updated by callback functions
Using the definition of What is the difference between properties and attributes in HTML?:
Attributes: Attributes are defined by HTML. They initialize DOM properties and then they are done.
Properties: Properties are defined by the DOM (Document Object Model). After DOM has been fully initialized these properties can change.
It is logic and reasonable to say that Dash Callbacks retrieve a specific DOM object by its id, and 'read' its property (not the HTML attribute that initialized it). Example: it is possible to have an Input Callback listening to a graph figure 'hoverData' change property.
If this assumption is true:
So basically dash Callbacks operate after the DOM has been initialized, also again they operate on DOM properties not HTML attributes.
So again if true case this could be clearly stated in documentation which would improve to avoid developers confusing this sometimes not very obvious terms.
Have found an answer, dash callbacks work with DOM Properties which is more accurate than saying HTML attributes.
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
Unreal Engine 4 provides three specifiers to control the visibility and editability of an C++ class member exposed to Blueprint via UPROPERTY().
The documentation in the UE4 source code (see also UE4 wiki, UE4 documentation) says the following regarding editability:
For VisibleAnywhere, VisibleInstanceOnly, VisibleDefaultsOnly:
... cannot be edited at all.
For EditAnywhere, EditInstanceOnly, EditDefaultsOnly:
... can be edited ...
For BlueprintReadOnly:
... can be read by blueprints, but not modified.
and BlueprintReadWrite:
... can be read or written from a blueprint.
Questions:
Since the Visible* specifiers already restrict the usage to read only in Blueprints, why it is used in conjunction with BlueprintReadOnly? Isn't the second specifier superfluous? Example:
UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Even more confusing is the usage of Edit* specifiers, which allow read and write in Blueprint, together with BlueprintReadOnly which restricts to read only in Blueprint. Aren't both specifiers opposing each other? Example:
UPROPERTY(EditAnywhere, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Are the Visible*/Edit* specifiers valid in a different context than the BlueprintRead* specifiers? (the question is not about InstanceOnly (property windows for instances), DefaultsOnly (property windows for archetypes) and Anywhere (instances & archetypes))
tl;dr
Visible*/Edit* specifiers allow you (typically a game designer) to access/modify a variable directly in Blueprint Editor for quick configurations of class properties.
BlueprintRead* allow you to get/set the value of a variable in the Event Graph when you're doing Visual Scripting.
Explanation:
Some namings and explanations in the official documentation are indeed a little ambiguous, especially for beginners. In a nutshell, both Visible*/Edit* and BlueprintRead* expose a variable in a class to the Unreal Engine, but do different things. In fact, both question 2 and 3 can be answered via question 1. Let's see your question 1:
Since the Visible* specifiers already restrict the usage to read only in Blueprints, why it is used in conjunction with BlueprintReadOnly? Isn't the second specifier superfluous? Example:
UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Here you're exposing an ActorComponent to the Engine. Here I'll explain a non-Component member variable first, because specifiers for Component "appears" to work differently from non-Component variables.
Suppose I have a TpsCharacter class for a Third Person Shooter character, which has the following 3 float variables:
// The zooming speed
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float ZoomSpeed;
// The FOV after zoom in
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float ZoomInFov;
// The default FOV
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float DefaultFov;
They're all specified as EditDefaultsOnly, which means that, after we create a Blueprint class called TpsCharacter_BP based on this C++ class and open this Blueprint, the values of these 3 variables are editable in the Details Panel for this Blueprint class, as shown in the picture:
Of course, by using Visible* specifiers, they are read-only (greyed out in the Details Panel) so you can't change their values.
Now let's get back to your MyActorComponent. Like I said, specifiers for Component works somewhat differently.
Component appear in the Components Panel together with its owner class in the Blueprint Editor instead of in Details Panel like a non-Component variable.
When you have neither Visible* nor Edit* specifiers for a Component, this Component itself will always appear in the Editor, but you can't access properties/variables inside this Component., and Details Panel for this Component will be empty.
Visible* specifier allows you to access the Component's properties via its Details Panel, just like accessing the 3 variables in my TpsCharacter_BP class. However, when you declare it as Edit*, the Details Panel will show wired settings, allowing you to modify the Pointer value of this Component rather than its contents. This is definitely one thing you should always avoid.
Rule of thumb for Component: NEVER declare them as Edit* because it allows you change the pointer value to point to other things; always do Visible*. For a non-Component object you're free to set Edit*.
Now it's much easier to understand BlueprintRead* specifier. Is it superfluous with the presence of Visible*? Is BlueprintReadOnly opposing Edit* specifiers? Absolutely no. Are they valid in different context? Yes. The BlueprintRead* specifier allows you to read/write a variable in the Event Graph in the Blueprint Editor, that is, when you're doing Blueprint Visual Scripting. For my TpsCharacter class above, since all 3 variables are declared BlueprintReadOnly, I can get their values inside the Event Graph as shown here:
You can do the same for your MyActorComponent. By using BlueprintReadWrite, you can also set the value for these variables in Event Graph.
I write such long answer to explain because they can really confuse beginners though they're actually simple concepts.
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)
I've been working on a component and currently I'm trying to do different things based on the selector chosen for the component.
So basically if I have a component with this structure
myComponent/
dialog.xml
myComponent.jsp
altView.jsp
I know that if I have a Node with resourceType myComponent I can request the alt view via browser by requesting "path/to/component/content.altView.html" and everything is hunky dory.
Similarly I can do a cq include and do something like:
# with cq include
<cq:include path="my/path.altView" resourceType="myComponent"/>
# or with sling include
<sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
However, when I'm handling the request, I've seen some interesting behavior when looking at the RequestPathInfo Object.
For example, if we look at all 3 of the above cases I might have something like this:
# http://path/to/component/content.altView.html
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <sling:include path="my/path" resourceType="myComponent" replaceSelectors="altView"/>
slingRequest.getRequestPathInfo().getSelectors(); // {altView}
slingRequest.getRequestPathInfo().getExtension(); // html
# <cq:include path="my/path.altView" resourceType="myComponent"/>
slingRequest.getRequestPathInfo().getSelectors(); // []
slingRequest.getRequestPathInfo().getExtension(); // altView
I understand why the cq:include returns different results (we're making a request to my/path.altView and .altView coincidentally serves as the extension in this case). I'm curious if there is a normalized why to pull "altView" (or the selected view) regardless of if it's been used as an extension or selector. Or if this is normal and I just need to check both the extensions and selectors individually.
i.e
selectors = get selectors();
if selectors
do stuff
else check extensions
do stuff
Again thank you very much for your insights, this community is awesome.
[EDIT]
In response to an answer, I thought I'd give a little more context to what I'm doing. Basically our component structure is set up so that each of our components has an associated Java Class that handles the business logic. (I.E. apps/myapp/components/myComponent will map to com.mypackage.components.MyComponent) That said, within my component's Class I need to handle the control flow differently depending on how the component was called (i.e. what selectors/extensions/etc). For example, if my component was called normally I'd do the base behavior, but if it was called with selector (for exmaple) "altView" I would need to handle the alternative view differently, and in this alternative view different data will be available, etc.
My question was along the basis that it seems that i can give the "path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/>
However, when I check my RequestPathInfo in my component class to decide workflow, "altView" is returned as the extension, not within the String[] selectors. Note, the above compiles fine, and it selectors the correct .jsp file for rendering, the RequestPathInfo object just stores the data in a different place.
I'm starting to guess that places the selector into the path attribute works because the selectors and extensions modifiers alter the behavior vary similarly. mycomponent.altView.html resolves to altView.jsp whereas if I was to do mycomponent.altView it would also attempt to resolve a mycomponent/altView.jsp just as it would do the same for mycomponent.xml to mycomponent/XML.jsp
It seems like you're kind of working around Sling resolution. The easiest way to do "different things based on selector" in a given component (let's say my/new/component) is to create different renderers.
For example, say I am requesting /content/app/page.html, and on that page was the component my/new/component. Or if I request /content/app/page.selector.html, I want a slightly different experience for my/new/component.
In the cq:component, I would create two JSPs: component.jsp and component.selector.jsp. Sling will automatically know, based on the selector in the request, which renderer to use. Obviously each renderer can produce a different experience.
The same is true for extension. In the example, component.jsp and component.selector.jsp are actually equivalent to component.HTML.jsp and component.selector.HTML.jsp. The HTML is just implied. However, you could do component.XML.jsp and component.selector.XML.jsp and Sling will again, pick the most relevant selector, based on the selector(s) and extension of the request.
Now, what if you don't want the selector to show up in the page request's URL (in my opinion you shouldn't)...
You can include your component using sling:include and add the selector, like you've done.
The caveat is that sling:include works a little differently than cq:include, so only use this when you need to. Instead, you could also use Sling mapping to hide the selector from the user. The majority of the time I would recommend this approach.
I'm not sure what you were trying to do with adding the selector to the "path" attribute. I don't think that would do anything. The "path" is defining the resource name (and the node name if the resource is not synthetic). Including the selector in that wouldn't do anything, except make the resource name include a period and the selector.
My question was along the basis that it seems that i can give the
"path" attribute of a "cq:include" tag the selector I want to use:
<cq:include path="my/path.altView" resourceType="myComponent"/> However, when I check my RequestPathInfo in my component class to
decide workflow, "altView" is returned as the extension, not within
the String[] selectors.
As opposed to the cq:include tag, you could alternatively use sling:include tag, which provides attributes to modify the selectors & suffix on the request:
<sling:include resourceType="myComponent" path="my/path" addSelectors="altView"/>
or
<sling:include resourceType="myComponent" path="my/path" replaceSelectors="altView"/>
If you already have selectors on the request that you don't want to apply to myComponent.
In terms of the differences between Sling include & CQ include, there seems to be very little, apart from the latter also supporting script inclusion. From the docs:
Should you use <cq:include> or <sling:include>?
When developing AEM components, Adobe recommends that you use
<cq:include>.
<cq:include> allows you to directly include script files
by their name when using the script attribute. This takes component
and resource type inheritance into account, and is often simpler than
strict adherence to Sling's script resolution using selectors and
extensions.