I've noticed if I do not use #observable in any of my web ui code all fields/members changes are picked up automatically with the data binding syntax.
The issue I run into is when picking one field in a class that extends WebComponent and applying the #observable annotation, now other fields dont bind correctly and display changes.
Is this a known issue or correctly functionality?
If I use #observable annotation once, should I be applying it to all fields?
As mentioned in another post, you have the option of marking a class with #observable.
You're currently caught between observables and watchers. Watchers (and dispatch) are the old way, soon to be phased out. Observables are the new way. In order not to break old clients, we kept watchers in. If you used at least one #observable, then the watcher system is disabled.
The new MDV v2 implementation is getting ready. I suggest you use #observable for anything you want observed. Stop using dispatch() everywhere. Also, stop using observable top-level fields, because they won't be bindable into a node.
Apologies, things are really in a state of flux. I suspect things will settle quite soon.
I suggest reading more about MDV v2 here: https://github.com/toolkitchen/mdv/blob/stable/README.md to get ready for the change.
I suspect #observable will continue to be an option, so it's OK to keep using that now.
From the documentation here, this seems by-design to me. The goal of the #observable is to mark that member as interesting for binding, unlike others.
You can also annotate the class itself with #observable if you don't want to annotate each field individually: Marking a class as #observable is the same as marking all of its fields as #observable
Today, I made a nice discovery about #observable: If you change an observed value outside of the component's dart code (using query("#component_id").xtag), the field needs to be marked as #observable - otherwise, the change to the value will not be noticed by the component.
Alternatively, after changing the value, one could call dispatch(). I'm currently testing what's faster, but I think it might be the annotation.
This is not a direct answer to the question, but it might be worth to consider this when deciding using the annotation or not using it.
Related
Once again, a Dart/Polymer related question.
I wanted to use the Parse.com JavaScript library, but since it's not available in Dart I've written Wrapper classes which store a JsObject and delegate all calls from Dart to the corresponding JavaScript object. Basically it's like a proxy.
Guess what, it works pretty great.
However, my observables don't. To understand this, you have to take a look at the following structure of one of my "proxy"-classes.
class ParseObject extends Observable {
JsObject _jsDelegate = new JsObject(context['Parse']['ParseObject']);
void set(String key, dynamic value) {
_jsDelegate.callMethod('set', [key, jsify(value)];
}
dynamic get(String key) {
return dartify(_jsDelegate.callMethod('get', [key]));
}
}
The HTML code of my Polymer Element looks like this:
<div>Name: {{project.get('name')}}</div>
Since the data binding is only evaluate in case the parameter of the method changed, it will never be updated and thus even though the name is changed, the old one will stay in place.
The solution I came up with is to store all the values the user is setting in the ParseObject#set(String, dynamic) method into a Map which is observable. This works but I think it's quiete dirty since I have to make sure that both Maps, the one in Dart and the one in the ParseObject's JavaScript representation equal.
Thus I am looking for a better solution and I think of some kind of method to tell Polymer to reevaluate it's data bindings.
Does such a method exist or are there any other possibilities to address this problem?
Extending observable by itself does nothing yet.
You need to annotate the getters with #observable (and if you are not using Polymer, you also need to add the observable transformer to pubspec.yaml). You can't make functions observable (this works in Polymer elements but not in Observable model classes. For more details about observable see for example Implement an Observer pattern in Dart or Dart: #observable of getters
How can I access an attribute that's been hidden via:
__attribute__((visibility("hidden")))
I'm trying to access UINavigationItemButtonView, but it seems sometime recent (iOS 7.1?) they've added the above into the header file. Recursively printing the window no longer reveals UINavigationItemButtonView in the view stack either.
So, given a UINavigationBar, how can I access a UINavigationItemButtonView that has been hidden via the above flag?
Printing all the subviews in UINavigationBar doesn't reveal it.
The attribute keyword is simply a message to the compiler, and has nothing to do with the runtime. Using ((visibility("xxx")) only serves to tell the compiler if the given declaration should be "visible" or usable by clients in some other package. visibility("hidden") just means that, despite the public declaration, make this thing invisible to external packages, so that they will not be able to use it. Compiling will fail if you attempt to use this class or method.
If you don't see this class being used in a recursive description, it is likely that this class is no longer used; it certainly isn't because of the attribute statement.
Since it's a private class, you shouldn't. Anything you do to bypass that restriction may result in your application failing the review process. Not to mention that, in general, accessing private and/or hidden API's, classes, instance variables, properties or whatever else it is, is a really good way to make sure your application breaks in the (not too distant) future.
In Polymer.dart I'm aware that there are no strictly observable getters, and that instead we need to use bindProperty() (Soon to be onPropertyChange()) and notifyProperty() to simulate the same thing.
Looking through various code samples, I see some locations where this is added in to the constructor of the PolymerElement's class, and others where the binding happens in the created() method. Is there a preference as to where binding should occur? Are there any significant benefits or detriments on putting them in one of these areas or another?
Putting bindProperty into the constructor no longer works in polymer.dart >= 0.8. I am in the process of changing all my samples.
I am now using created as the location where I put my onPropertyChange or similar calls.
Why does MouseEvent.toElement return Node?
I'd assume it should return Element, or the method should be renamed toNode.
As it stands, having the dart editor warn me about accessing the style property when I write the following is less than ideal:
event.toElement.style.textDecoration = "line-through";
I believe it's called toElement() to keep it aligned with what we have already in the DOM/JavaScript land. It was named by Microsoft long ago and has been adopted in several browsers today. So, I think in Dart we wanted to keep the same name.
However, whether we should annotate it to return Node or Element, that's a good question. I believe in almost every (if not all) cases the returned object is indeed an Element and it would be nicer if it was typed to return an Element. However, there may be corner cases where it actually returns a Node (remember, elements extend nodes). With quick testing, I couldn't find any such case. Maybe with manual event firing.
Maybe the Dart engineer behind this choice can shed us some light.
I would like to do coloring in Eclipse without using the presentation reconciler. Therefore, first, I need to figure out how to associate a TextPresentation object with either my editor or document, but I am having difficulty finding out how to link it either of those. Normally, the CreatePresentation in the IPResentationReconciler interface would give the style range to the textpresentation, and from there Eclipse would know what to do with that presentation object. Is there some way to use a TextPresentation object without the use of PresentationReconciler? It would be nice if I could do coloring without the use of reconciler. Thank you.
I finally figured out how to achieve the coloring without the use of Reconcilers.
I discovered that first I needed a way to obtain a reference to my SourceViewer object, as I am extending TextEditor. I also discovered that I could implement the TextListener interface and add my own listener to the SourceViewer object. One must be careful, however, as calling the getSourceViewer() method can result in null if not called at the appropriate spot. Originally, I overwrote the init(...) function in my editor class and made the getSourceViewer() call, but it still resulted in null. After doing a bit of research, I discovered that I could properly obtain a reference to the SourceViewer object by overriding the createPartControl method. I first call super.createPartControl(...) and then make a call to getSourceViewer(). After I obtained that reference, I used that with my listener class I created and was able to do the coloring myself with the setTextColor method the SourceViewer object has. Hope this helps others in the same situation.