Unlike Swing Javafx-8 doesn't appear to have "setEnabled()" methods (or equivalent) for UI controls. Suggestions for workarounds?
You can use setDisable() instead of setEnabled() in javaFx..
like button.setDisable(false)
setDisable is a public method for disabling a node, setDisabled is a protected method used only by internal implementations
Related
How do I completely disable using "builders" in MapStruct? I don't want to use them at all as they are causing all kinds of issues for me.
I created the service file under META-INF (I would prefer a way to assign it to the mapping builder= but I did not see any examples how to do it right in code).
It is still trying to use Immutables "builder" instance instance of the "ModifiableXXX" instance I want to map to. I'd even take a way of forcing it to the modifiable type if that is available.
In another mapping, using an update the ModifiableXXX (with #AfterMapping and #MappingTarget) approach works.
My mapper looks like this right now:
#Mapper
public interface MongoProjectMapper
{
ModifiableProject mapModel(MongoProject project);
#AfterMapping
ModifiableProject updateProject(MongoEntity e, #MappingTarget ModifiableProject p);
}
From Mapstruct version 1.3.1.Final we can use annotation org.mapstruct.Builder#disableBuilder within: #BeanMapping, #Mapper or #MapperConfig
#Mapper(builder = #Builder(disableBuilder = true))
public interface ProjectMapper
Have a look at #mapping-with-builders and documentation
Completely disabling builders is possible via the NoOpBuilderProvider. You need to create a org.mapstruct.ap.spi.BuilderProvider file in the META-INF/services directory with org.mapstruct.ap.spi.NoOpBuilderProvider as it’s content. This will completely disable the builders.
There is a feature request to make this more granular and disable it via #BeanMapping or on the mapper level. Have a look at mapstruct/mapstruct#1661
Most of the gwt mvp tutorials show the view interface declared as an inline interface in the presenter class. Is there a good reason for doing that or is creating a separate file for the View interface a better choice or does it just not matter (I know it doesn't matter for the compiler).
public ItemPresenter {
...
public interface MyView<> {
public void setName(..);
}
...
}
Thanks.
There's no technical need to use an inner interface. It will definitely work with separate compilation units.
I personally prefer inner interfaces as the presenter together with the view interface define the contract how these two communicate with each other.
Another reason for me is naming. Think about ItemPresenter & ItemView vs ItemPresenter & ItemPresenter.View. For me the latter is more intuitive as the View is defined by the presenter itself.
And the last reason is copy&past. Yes, that's right :)
For presenters/views as well as Events with inner handler interface, I have empty copy&paste templates in my workspace. With the inner interface you won't have trouble with imports when copying the template.
It doesn't matter what you do. It is just to bring things closer together.
I had convenience methods littered all over the place. I have now pushed these in to a couple of helper classes and I made the helper classes protected members of my layer supertypes.
Everything was going along swimmingly until I came to Zend View. I have extended Zend View to make my layer supertype but when I try to attach a protected member it throws a:
Zend View Exception: Setting private or protected class members is not
allowed.
Firstly, why would such members not be allowed? Any ideas? Secondly, have you circumvented it in the past? And how did that go? (It seems that the framework detects protected members by the presence of a leading underscore. This seems a bit hit-and-miss, and also easy to get around).
Note - I'm not saying that I would circumvent it. I'm just trying to find out what others have done in the past (since it seems an odd constraint).
It's an important point for me since I am using traits to bring the helpers and associated proxy methods into each superclass. I don't want to maintain a separate trait just for the View. Alternatively, I don't want to make the helpers public members of each superclass.
Thank you!
Data encapsulation.
Underscore properties are not allowed primarily so that the developer can't accidentally overwrite View properties that are part of the framework.
This essentially protects all of the framework's View properties and allows you, the developer, free rain over any public properties you wish to set.
The authors of Zend View can then be sure of two things: (1) they control (and author) the private and protected class properties and (2) you control the public properties. This makes for logical data encapsulation and maintainable class overloading.
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.
I just started using the Netbeans 7.1 beta and it is calling out errors of a type which I have never seen before. Specifically:
A managed bean with a public field should not declare any scope other than #Dependent.
The fields it is complaining about are public static final. I can understand the restriction on non-static fields, but I can't think of a good reason this would not be allowed for a static field. Unfortunately I use a lot of them since I don't like having constants in my code.
I note that even though I get the red dot in the margin in the editor, the maven-driven build still works and GlassFish still runs my application the way I would expect.
So what is my denoument on this issue? Am I going to have to move my static fields elsewhere or is there another way of handling this?
Quoting the javax.enterprise.inject package javadocs:
If a managed bean has a public field, it must have scope #Dependent.
But I do agree wih #BalusC that if this compiles, Netbeans should report it as Warning (does it?).
Anyway, are those constants really part of the API? I mean, do you access they anywhere else but within their own classes? If not, reduce visibility to private. (If you just need to access the constants from the view you can also create accessors for the private constant). If yes, I would suggest you to move them somewhere else anyway.
Public fields (static or not) aren't proxyable - that's why they can only be dependent scoped. To work around this you obviously can access them through getter methods.