# lit-element -> Properties -> Configure attributes -> Configure observed attributes
it refers that:
By default, LitElement creates a corresponding observed attribute for all declared properties.
and
To prevent an observed attribute from being created for a property, set attribute to false. The property will not be initialized from attributes in markup, and attribute changes won’t affect it.
Clarification:
When an observed attribute is prevented, the property is still observable within the element, isn't it?
Tia
Yes. The property will still be accessible from within javascript, and will trigger re-renders.
Related
Given:
#property({type: Boolean, attribute: 'some-attr'}) someAttr = false;
I was expecting to see updated being fired once 'some-attr' value gets updated in the DOM.
However, updated doesn't get fired at all.
Is my expectation wrong, or should I set things up differently?
Looking at Elm's discussion of properties vs attributes, the documentation of the Html.Attributes module's attribute function, and the Elm documentation on custom elements, I am pretty sure, that this is caused by simply binding an elm expression to attribute some-attr of the LitElement based custom element. I.e. the DOM attribute will always be present and hence the corresponding property always be true.
The default converter for Boolean (activated by providing type:Boolean to the decorator) mimicks the behaviour of HTML attributes used as flags (e.g. disabled on an <input> element): If the attribute is present (no matter the value), the flag is set (true). The implementation is really straight forward, if you want to look at it in the sources: https://github.com/Polymer/lit-element/blob/master/src/lib/updating-element.ts#L163
I see these options for your problem:
Implement some extra logic in Elm to add / remove the presence of the attribute.
Create your own attribute converter for the LitElement based custom element.
Use another default converter (e.g. for String, the "default" default converter) and implement the custom logic inside the LitElement (e.g. using a derived value).
Of these 3 options, I would generally recommend the first one, as your custom element then still behaves naturally, i.e. if some-attr should be a flag (boolean attribute), then following which HTML semantics, it should be defined by its presence, not its value. This allows you to re-use it in other projects without surprising other developers.
That being said, there may of course be project-specific requirements, that are more important. E.g. if you only use this custom element in this one project with Elm, your road to success may be faster going for options 2 or 3.
In an EA model I have a class. The class defines an attribute. I want to be able to have an instance of this class (an object) with the attribute visible on a diagram and the ability to link specifically to that attribute (as in the Link to Element Feature option).
Is it possible?
Yes and no. You need to set the run state of the object
Once the following dialog is completed, it can look like
The value is free text and not linked to the original attribute, but better than nothing.
I have a custom property in my custom control. The custom property is in the Field1 group and is called ClientID. The group and the field are in my custom property definition. I want to set it on page load. So I do the following:
compositeData.Field1.ClientID = getClientId("Field1")
When I do do I get an error:
'compositeData.Field1' is null
But if I define a property off of the root called Field1_ClientID and do the following:
compositeData.Field1_ClientID = getClientId("Field1")
Then all works well. How can I make use of groups in custom properties?
Bruce,
compositeData is a property map. If there is no value in it, compositeData.Field1 will be a null (because it is also a property map).
So you can do this;
compositeData.Field1= { ClientID: getClientId("Field1") }
To set the property "property1" within the group "group1" you can do the following:
compositeData.group1.property1 = "test";
You can run the above code in the beforePageLoad or afterPageLoad events of the custom control.
I think that your problem is that you are setting the value in an event which takes place before the custom control has been set up.
Ok I did a quick test of the group functionality of the custom control (never used it before).
given a group of "testGroup" and property of "testProp" inside that group.
The following worked in beforePageLoad:
compositeData.testProp = "example1";
print("Test1: " + compositeData.testProp);
the following did not work:
compositeData.testGroup.testProp = "example2";
print("Test2: " + compositeData.testGroup.testProp);
I therefore believe the group property may simply be a way of logically grouping properties and not defining an object with multiple properties. Try just referencing the property and not the group.
I don't think this is an uncommon problem, but I haven't been able to make any of the solutions I've found work. Here's my [simplified] view:
class MyView extends Backbone.View
el: '#mydiv'
initialize: ->
#collection.bind 'reset', #render, #
render: ->
$(#el).html('my content')
When reset is triggered, render's this has been clobbered, and #el is undefined. My understanding was that the 3rd parameter on bind was supposed to take care of this, but that doesn't appear to be happening. I am using Backbone 0.5.3.
I also tried using the "fat arrow" on render, but that didn't work either:
render: =>
$(#el).html('my content')
Update
As Trevor Burnham pointed out below, it wasn't a scoping issue, it was that my el property wasn't available at page load (it get's created later). I'm still looking for a better way to deal with that (using the id property on the view).
I don't think the problem is that render is called in the wrong context, but rather that the view's el property is never a DOM element. Does something with the ID mydiv exist at the time that you call new MyView? If not, that's the problem.
Internally, when el is a string, Backbone makes the call
this.el = $(this.el).get(0);
from the view's constructor. If nothing matching that selector string exists, #el will be undefined, which is what you're seeing.
Use the double arrow => instead of single-arrow -> when defining your render method, and CoffeeScript makes sure that the this pointer points to the class instance. Also, you may want to try to set the id member to the id reference instead of the el member, as the documentation for backbone (http://documentcloud.github.com/backbone/#View-el) indicates that el gets created (by backbone itself) based on whatever id, tagName and className is set to.
Could someone point me in the direction of how to create a custom "Inject" attribute with Ninject?
I would like to do the following:
InjectView - custom "inject" attribute
When a property with this attribute is to be injected, the injected value is to be loaded from a "ViewManager" class.
I found an example with ISelector to decide if the property / filed is to be injected, however I couldn't find out how to add a custom "injection strategy" for this - I would like to delegate the injection of the actual value to my ViewManager.
It's already supported and can be done with a simple configuration of the kernel.
new StandardKernel(new NinjectSettings() { InjectAttribute = typeof(MyOwnInjectAttribute) };
I solved this by adding a custom IInjectionHeuristic which allows injecting by my custom attribute. Then I also added a custom IBindingResolver which adds an additional binding per type that is resolved - this binding has a condition checking for the custom attribute, so that it doesn't break any previous bindings...
Tha bindings created by the custom IBindingResolver sets a local "ProviderCallback", which utilizes the extracted property and passes the request to an internal ViewRegionManager instance.
Hope this helps in case anyone wants to do something similar in the future.