A ValueAwareEditor has a method void onPropertyChange(java.lang.String... paths), about which the javadoc says: "Notifies the Editor that one or more value properties have changed."
When exactly is this method called? Is it the duty of the EditorDriver to call this method? Or do I have to implement code that calls this method myself?
Or is it simply not implemented yet at all, which is suggested by this question: GWT editor onPropertyChange.
That method is never ever called by the two built-in editor drivers (git grep onPropertyChange returns only method declarations), so I guess we can say that this is "simply not implemented yet at all".
Note that EditorDelegate#subscribe() is implemented in RequestFactoryEditorDriver using the alternate approach to comunicating change: it'll listen to EntityProxyChange events and will RequestFactory#find() the proxy back when changed, and then update the editor in-place, notifying ValueAwareEditors and LeafValueEditors via their setValue().
subscribe() is a no-op for the SimpleBeanEditorDriver.
Related
How is the PropertyChanged event used?
I'm wanting to evaluated the next state of a state machine whenever any property of the class is changed.
Regards Steve
PropertyChanged is part of the standard IPropertyNotifyChanged signaling.
If you want to create side effects if any change is done - consider setting "HasUserCode" on each attribute, Generate code, now you will find a partial method available for you to fill for Set and Get of attributes.
In a setter you can have side effects like running a trigger to step a state machine.
I am looking through the Xamarin Sport app code and trying to understand some of the cool things they are doing in it. I cannot understand what IsDirty is being used for exactly. It gets defined here and implemented here and used in many places, such as here.
I read a little about and ICommand's IsDirty property so maybe it is a way to call an entire model as being dirty, but what implications does that have?
I also see it being used here which I am assuming is why they created it in the first place.
Thanks for y'all's insight into it.
They're just using it as a clever way to handle modification detection. Consider a "Save Changes" feature; you don't actually want to enable the "Save" button until something has changed, and you can key off the IsDirty property to test that.
Technically, you could handle this yourself by having a base class hook INotifyPropertyChanged.PropertyChanged and maintaining a dirty bit of your own (possibly in a base class), but rather than require all of their classes to have an IsDirty property that they may or may not need, they've made it an optional feature that a class can implement. For example, take a look at GameResult for an example of something that can't be changed, and therefore, can't be marked as dirty.
With this approach, you've minimized the amount of code you need to write to implement this functionality. All your derived classes need to do is derive from BaseNotify, implement IDirty, and call SetPropertyChanged(...) as the setter to set the private tracking field, signal to any observers that a property has changed, and automatically set the dirty bit.
NOTE: I did just make an interesting observation: while the implementation of the SetProperty extension method does set the IsDirty flag, the BaseNotify class' IsDirty implementation doesn't call anything to bubble up a PropertyChanged event for IsDirty, which means bindings against it won't get updated when it changes. I believe the fix would be for that extension method to invoke PropertyChanged with the property name "IsDirty":
if(dirty != null) {
dirty.IsDirty = true;
handler.Invoke(sender, new PropertyChangedEventArgs("IsDirty"));
// Yes, I'm a bad person for hard-coding the name.
}
Alternately, you could defer signaling the IsDirty change until after you signal the original property has changed. I just chose to keep it with the original logic.
I think it's relatively simple and you're on the right track: the purpose of that property is to have an easy way to know whether some property has been changed, so the whole object has to be saved. It's baked in to the way property changes are propagated, so you don't have to set it by yourself whenever a property value is being set.
tl;dr: You can use it to check if you your (view)model is worth a save operation ,-).
From within a class derived from FB::PluginCore (or FB::JSAPIAuto), for example in onPluginReady() or a JS method handler, I'd like to have access to the NPP instance. What is the best practice for getting this pointer?
The underlying goal is to be able to call NPN_SetValueForURL, to set cookies.
You can call any of the NPN functions on the NpapiBrowserHost object, which is what the BrowserHost actually is.
FB::Npapi::NpapiBrowserHostPtr npapiHost = FB::ptr_cast<FB::Npapi::NpapiBrowserHost>(m_host);
I think it has SetValueForURL on it, but if it's missing you can always add it and submit a pull request; I'll accept it as long as it's reasonable.
Hi I am trying to learn JAVA deeply and so I am digging into the JDK source code in the following lines:
URL url = new URL("http://www.google.com");
URLConnection tmpConn = url.openConnection();
I attached the source code and set the breakpoint at the second line and stepped into the code. I can see the code flow is: URL.openConnection() -> sun.net.www.protocol.http.Handler.openConnection()
I have two questions about this
First In URL.openConnection() the code is:
public URLConnection openConnection() throws java.io.IOException {
return handler.openConnection(this);
}
handler is an object of URLStreamHandler, define as blow
transient URLStreamHandler handler;
But URLStreamHandler is a abstract class and method openConnection() is not implement in it so when handler calls this method, it should go to find a subclass who implement this method, right? But there are a lot classes who implement this methods in sun.net.www.protocol (like http.Hanlder, ftp.Handler ) How should the code know which "openConnection" method it should call? In this example, this handler.openConnection() will go into http.Handler and it is correct. (if I set the url as ftp://www.google.com, it will go into ftp.Handler) I cannot understand the mechanism.
second. I have attached the source code so I can step into the JDK and see the variables but for many classes like sun.net.www.protocol.http.Handler, there are not source code in src.zip. I googled this class and there is source code online I can get but why they did not put it (and many other classes) in the src.zip? Where can I find a comprehensive version of source code?
Thanks!
First the easy part:
... I googled this class and there is source code online I can get but why they did not put it (and many other classes) in the src.zip?
Two reasons:
In the old days when the Java code base was proprietary, this was treated as secret-ish ... and not included in the src.zip. When they relicensed Java 6 under the GPL, they didn't bother to change this. (Don't know why. Ask Oracle.)
Because any code in the sun.* tree is officially "an implementation detail subject to change without notice". If they provided the code directly, it helps customers to ignore that advice. That could lead to more friction / bad press when customer code breaks as a result on an unannounced change to sun.* code.
Where can I find a comprehensive version of source code?
You can find it in the OpenJDK 6 / 7 / 8 repositories and associated download bundles:
http://hg.openjdk.java.net/jdk6/jdk6 - http://download.java.net/openjdk/jdk6/
http://hg.openjdk.java.net/jdk7/jdk7 - http://download.java.net/openjdk/jdk7/
http://hg.openjdk.java.net/jdk8/jdk8
Now for the part about "learning Java deeply".
First, I think you are probably going about this learning in a "suboptimal" fashion. Rather than reading the Java class library, I think you should be reading books on java and design patterns and writing code for yourself.
To the specifics:
But URLStreamHandler is a abstract class and method openConnection() is not implement in it so when handler calls this method, it should go to find a subclass who implement this method, right?
At the point that the handler calls than method, it is calling it on an instance of the subclass. So finding the right method is handled by the JVM ... just like any other polymorphic dispatch.
The tricky part is how you got the instance of the sun.net.www.protocol.* handler class. And that happens something like this:
When a URL object is created, it calls getURLStreamHandler(protocol) to obtain a handler instance.
The code for this method looks to see if the handler instance for the protocol already exists and returns that if it does.
Otherwise, it sees if a protocol handler factory exists, and if it does it uses that to create the handler instance. (The protocol handler factory object can be set by an application.)
Otherwise, searches a configurable list of Java packages to find a class whose FQN is package + "." + protocol + "." + "Handler", loads it, and uses reflection to create an instance. (Configuration is via a System property.)
The reference to handler is stored in the URL's handler field, and the URL construction continues.
So, later on, when you call openConnection() on the URL object, the method uses the Handler instance that is specific to the protocol of the URL to create the connection object.
The purpose of this complicated process is to support URL connections for an open-ended set of protocols, to allow applications to provide handlers for new protocols, and to substitute their own handlers for existing protocols, both statically and dynamically. (And the code is more complicated than I've described above because it has to cope with multiple threads.)
This is making use of a number of design patterns (Caches, Adapters, Factory Objects, and so on) together with Java specific stuff such as the system properties and reflection. But if you haven't read about and understood those design patterns, etcetera, you are unlikely to recognize them, and as a result you are likely to find the code totally bamboozling. Hence my advice above: learn the basics first!!
Take a look at URL.java. openConnection uses the URLStreamHandler that was previously set in the URL object itself.
The constructor calls getURLStreamHandler, which generates a class name dynamically and loads, and the instantiates, the appropriate class with the class loader.
But URLStreamHandler is a abstract class and method openConnection()
is not implement in it so when handler calls this method, it should go
to find a subclass who implement this method, right?
It has to be declared or abstract or implemented in URLStreamHandler. If you then give an instance of a class that extends URLStreamHandler with type URLStreamHandler and call the openConnection() method, it will call the one you have overriden in the instance of the class that extends URLStreamHandler if any, if none it will try to call the one in URLStreamHandler if implemented and else it will probably throw an exception or something.
I am currently implementing an Eclipse-Plugin which is using the standard properties view, connected to a Navigator. It also features a textual editor, which is able to connect regions within its' document to certain objects that can supply properties to the PropertiesView (i.e. the same objects, that are displayed in the Navigator).
However, the Tuturials I found only dealt with Views that used a pre-implemented Viewer, which already supported passing on the selected element to the Properties View.
The TextEditor does not do that (I am using jface and a subclass of the AbstractTextEditor class), because it's SelectionProvider returns informations about the offset and the length of the selection only.
How do I have to modify the SelectionProvider of my TextEditor, such that it provides information usable to the Properties View?
Thank you in advance
Okay, I have managed to find the solution myself.
First of all, I had to implement the getAdapter() method in my subclass of TextEditor such that it returns an Adapter for IPropertySourceProvider, that can deal with the type of elements that are selected in my AbstractTextEditor.
Then, I implemented an ISelection that extended TextSelection, in order to not interfere with any selection-specific mechanism supplied by the AbstractTextEditor, and implements the interface IStructuredSelection, because the Properties View works with this interface of ISelection only.
An IStructuredSelection features basic methods of an array, however, in my case it is only possible to ever select only a single element, so implementation of these methods were trivial.
The last step was to get my ISelection to the right place. Overwriting the getSelection()-method of the ISelectionProvider of the AbstractTextEditor did not suffice, because obviously, the methods of firing SelectionChangedEvents does not use this method.
Thus, instead of using a standard SourceViewer, I used my own implementation in which I basically overrid the methods fireSelectionChanged(int offset, int length) and firePostSelectionChanged(int offset, int lenght), such that they use events containing my ISelection.
The rest is implementing the handling of my Objects in the Adapter for IPropertySourceProvider in a way that it returns an IPropertySource for the given Object, as it is shown in various tutorials.