jfxtras CalendarTextField cannot be loaded in Scene Builder - javafx-2

I am using Netbeans and Scenebuilder to create a JavaFX project. I realized that Scenebuilder does not have a date picker component so I downloaded the jfxtras and added the library to my classpath. I used the following code to add the CalendarTextField Object to my FXML file:
<?import jfxtras.labs.scene.control.*?>
<CalendarTextField fx:id="setupdate" prefWidth="200.0" showTime="true" GridPane.columnIndex="3" GridPane.rowIndex="8" />
It appeared to have worked ok, however, when I opened my FXML file in Scenebuilder I am getting the following error:
fxml:99: error:
javafx.fxml.LoadException: Element does not define a default property.
I am not sure what this means.

Java 8 DatePicker
Use Java 8 + SceneBuilder 2, it has a DatePicker.
Both are early access (especially SceneBuilder 2). Don't expect much in the way of SceneBuilder 2 stability for a little while, it's implementation is currently pretty rough and not as polished as SceneBuilder 1.1.
jfxtras and fxml
With regards to the use of jfxtras controls in SceneBuilder 1.1, my guess is that it is just not supported.
In order to build the jfxtras controls for Java 7, it was necessary for the jfxtras developers to make use of private APIs as feature complete public APIs for building custom controls are not available in Java 8. Usage of private APIs may cause compatibility issues with different SceneBuilder versions as it ties the control binaries to only work with certain JavaFX versions (as backward compatibility of private JavaFX apis is not guaranteed in new Java versions).
Also, the jfxtras developers may not have implemented the builder classes required to make their controls work with FXML. This would seem to be the case, as lack of an appropriate builder is what generates the error: javafx.fxml.LoadException: Element does not define a default property.
Implementing your own builder
You can read more about builders and fxml in an Introduction to FXML. You could implement a builder for the jfxtras CalendarTextField if you wish (I will not write one in this answer though). If you did implement an appropriate builder, there is a reasonable chance that you would then be able to use the control in FXML used by SceneBuilder 1.1.

Related

Two JSF libraries providing the same renderer

Short Version:
If two JSF library jar files both include a custom renderer for the same family and type, is there any way from within the library itself (i.e. not from the containing app) of specifying which one should be used? Something like assigning a priority, with higher ones used in preference to lower ones?
Longer Version:
I'm using Primefaces in a project and trying to override the provided head renderer with my own:
<render-kit>
<renderer>
<component-family>javax.faces.Output</component-family>
<renderer-type>javax.faces.Head</renderer-type>
<renderer-class>com.example.MyHeadRenderer</renderer-class>
</renderer>
</render-kit>
If I put that into the WEB-INF/faces-config.xml of the war file then it's all good, and my renderer gets used.
However, if I try to deploy my code as part of a library jar (my-utils.jar), with the renderer defined in META-INF/faces-config.xml, then the Primefaces one is used. This contains exactly the same definition, so I'm guessing it just depends on the order they get loaded. Indeed, renaming my library to "xx-comps.jar" works, so it would appear that JSF is loading faces-config.xml files from all jar files in alphabetical order, with later entries just overwriting earlier ones.
Is there any way of forcing the selection to my library?
So far, I have these options:
Put my renderer directly into the WEB-INF/faces-config.xml of the war.
Build a custom Primefaces jar with that one renderer definition
removed.
Rename my library and rely on some (undocumented as far as I can
see) behaviour from the JSF loader.
Add a custom renderkit which extends the standard one, and reference
that from my war WEB-INF/faces-config.xml.
The first three all work but are not ideal, as (1) and (2) require changes outside my library, and (3) just looks dodgy as hell....
The fourth is just an idea as I've never written a render kit before so not aware of the effort involved. No idea if it is practical or would work, but it is better than (1) because at least the application only references a single render kit, and does not need to be updated if/when new renderers are added. Happy to put more effort into researching this approach if it seems a reasonable solution.
Also, I'd ideally prefer to use annotations rather than XML:
#FacesRenderer(componentFamily = "javax.faces.Output", rendererType = "javax.faces.Head")
public class MyHeadRenderer extends Renderer {
...
}
Thanks
You can specify the ordering via <ordering> in faces-config.xml of the JAR.
E.g. if you want your utility library to be loaded after all others, then just do so:
<ordering>
<after>
<others />
</after>
</ordering>
If you want to force an explicit ordering, then hook on specifically PrimeFaces, which has a <name>primefaces</name> in its faces-config.xml:
<ordering>
<after>
<name>primefaces</name>
</after>
</ordering>

Overriding a controls renderer

I'm having the following issue with the OpenNTF Bootstrap4XPages plugin: the NamePicker control uses a the Bootstrap renderer which displays it without the search field or the "add" field. I have raised this an issue on OpenNTF but in the meantime, I figured I would attempt to apply the ExtLib renderer for this control.
To date I have tried adding "com.ibm.xsp.extlib.OneUINamePicker" directly to the Renderer-Type property on the control (didn't work), added a renderer property set (taken from the ExtLib source) to the faces-config.xml (didn't work) both with theme enabled and disabled on the control.
So my questions are a) is this possible and b) if so, what am I doing wrong?
Thanks to Tim's comment, I had a moment of clarity in which I realised that I had been an idiot and had overcomplicated matters. I didn't need to worry about changing the renderer-type/adding a custom renderer. The simple answer was just to disable the theme for the NamePicker control which then forced it to use the ExtLib renderer anyway, giving me back the search button and both fields, albeit without styling.
The issue only occurred with the Bootstrap 3 themes. In the Bootstrap 2 themes, the correct renderer class was used.
I traced this down to a bug in the ExtLib theme file for Bootstrap 3. I've fixed it in the source code by setting the correct renderer class, so this will be solved in the next release.
See also: https://github.com/OpenNTF/Bootstrap4XPages/issues/59

Omnifaces: Using CombinedResourceHandler with Richfaces

when using CombinedResourceHandler in a Richfaces application only stylesheets and user defiend scripts are combined. The standard JavaScript resource and all Richfaces specific resources remain as seperated resources.
The Omnifaces documentation states:
RichFaces has the same problem with several JS files, but this is so far not exactly trivial to workaround
So my question is what this 'non-trivial workaround' would be?
As far as I can see, CombinedResourceHandler wont handle resources when getRendererType() returns org.richfaces.renderkit.ResourceLibraryRenderer. These are then handled by org.richfaces.renderkit.html.ResourceLibraryRenderer.
I am not sure what would be the best way to combine RichFaces behaviour with OmniFaces here.
I was able to create a solution by modifying OmniFaces CombinedResourceHandler.
Details in short:
Richfaces utilizes a concept called ResourceLibrarys wich means a resource may not only be a single file but instead a collection of those files. For example, RichFaces uses a resource named base-component.reslib. RichFaces ResourceHandler interpretes this resource dependency as dependency to
javax.faces:jsf.js
jquery.js
richfaces.js
richfaces-base-component.js
So the CombinedResourceHandler needed some extra functionality to seperate dependencies to ordinary Resources from Richfaces ResourceLibraries. The latter needed to be resolved according to specifications obtained from RichFaces sources.
It was not trivial to work this around without modifying the CombinedResourceHandler itself. The CombinedResourceHandler itself has really to be modified to use a reflection hack which extracts the resources from RichFaces' org.richfaces.resource.ResourceLibraryFactoryImpl. The reflection hack is necessary in order to keep OmniFaces free of RichFaces dependencies so that it can be used together with other component libraries like PrimeFaces.
As per issue 107, this was implemented in 1.3-20121206.

What is the best way to design the GUI in javafx 2.0?

In javafx 2.0 it is possible to create the layout by using FXML approach or by using normal java code.
What is the best way with respect to a well designed set of UIs. In my application there is about 100 sub UIs.
Thanks
FXML looks more logical for that purpose. By using FXML
you split business logic from view
you get option to edit design without recompiling project.
you get design as structured xml tree which is much easier to edit comparing to potentially randomly ordered java code
with SceneBuider tool you get an option to use visual editor for your fxml files
Get JavaFX Scenebuilder here.
FXForm2 is a library providing automatic JavaFX 2.0 form generation.
however FXForm2 is not full WYSIWYG GUI design tool.
http://dooapp.github.io/FXForm2/
Scene builder should be a good starting point to create unique UIs of your application. Considering you have 100s of UIs, I assume that some of their "appearances" should be identical with slightly different functions. You can load the FXML dynamically and assign controller at run time. Which means 1 FXML file can be used with multiple controllers. Which can save you some time while keeping the code dynamic for easier maintenance.
FXMLLoader loader = new FXMLLoader(getClass().getResource("DBedit.fxml"));
loader.setController(new DBeditEntityUser());
So, to make use of the same FXML with a different controller.
FXMLLoader loader = new FXMLLoader(getClass().getResource("DBedit.fxml"));
loader.setController(new DBeditEntityUserLevel());
Hope this helps.
fyi,
road map for Java fx http://javafx.com/roadmap/ shows that the scene builder will be released around middle of the year. From the above web page:
"JavaFX Scene Builder is a WYSIWYG GUI design tool for the
JavaFX platform. It enables designing user interface screens by simply
dragging and positioning GUI components from a palette onto a scene.
The tool generates files in FXML format2 that can be used within a project
in any IDE such as NetBeans or Eclipse. The JavaFX Scene Builder can be
used to create GUI for desktop applications and applets that run in a browser."

MonoTouch 5 Error: "Failed to find selector setXxxxxx" after migrating to Xcode 4.2 and MonoDevelop 2.8

I have an iPad project that has been under development in Xcode 3.2.6 / MonoTouch 4.2.x / MonoDevelop 2.6 and when I installed the Monotouch 5, MonoDevelop 2.8.1 and Xcode 4.2 the project compiled and run OK. But when I started to change the XIB files in Xcode 4.2 (adding outlets) I started to have some glitches:
1) App crashes and MonoDevelop in debug mode says the the views were not loaded because the view outlet was not set. I figured out that in Xcode 4.2 there is no need to create an outlet named "view" in the .h file and just need to connect the File Owner view to the view control in the designer. Correct?
2) The main problem and is not solved yet is that I get exceptions "Failed to find selector setXxxxx" where "xxxxx" is a name of an outlet for a UI control. It started to happen in ViewControllers that inherited from a base view controller, but as soon as I started to change other normal viewControllers I get the same type of errors. Any hints of what is wrong?
3) I have a controller that loads dynamically some views and that works fine. but when I set a property on one of this sub views outlets (like the Text of a UILabel) the value is set (on the debugger) but no change in the UI. The actions for example work fine. What could be wrong.
4) Any special settings in the XIB's that are needed in order to correctly under Xcode 4.2 to integrate well with MonoDevelop 2.8?
Help is much appreciated, I thought in going back to the previous set of tools and monotouch but I guess once the project was upgraded there is no way to go back without losing all the development done now.
Thanks, Pedro
EDIT: Beside the new clean attributed [Outlet] code generated by MonoTouch 5 (replacing lot of code previously generated), the significant difference is that before the partial class generated was public and now is private, this may be the source of my problem. Is there a way to generate public partial classes or protected?
EDIT 2: If I manually add the public keyword to the partial class and members generated by MonoTouch in designer.cs the selectors are generated behind the scenes and all works. This indicates that with the change from public to private partial class the bindings generation changed in MonoTouch 5, is it by design or bug? I would find it very strange that now its not possible to create a viewcontroller with outlets, subclasss it and the child viewcontroller cannot access the parent class outlets.
1) There is indeed a view outlet on the base UIViewController class, which is an Objective-C property. When using Interface Builder 3 with MonoTouch, IB often didn't allow connecting to the base view outlet so many users created their own in their custom subclasses. MonoDevelop 2.6 and older created these custom outlets as ivars (Objective-C fields), and apparently the UIKit runtime would connect the object to both versions of the outlet - both the custom ivar and the base property. MonoDevelop 2.8 generates the custom outlets as properties, which means that the redundant view outlet shadows the base view outlet, so the base view outlet is never set, and UIKit gets unhappy. You can fix this by removing the redundant custom view outlet - MD 2.8.2 will do this automatically.
2) Seems to be a bug with the way MonoTouch exports custom outlets that prevents connecting to custom outlets defined in base classes. A possible workaround is mentioned on the bug report.
3) The UI rendering won't update while your app is paused in the debugger, it'll update on the next mainloop iteration.
4) Nope.
5) The class accessibility should be controlled by the user class part, not the designer class part, so you can freely change it.

Resources