Archive for the ‘Uncategorized’ Category

Processing GET request parameters in JSF 2.0

Friday, April 23rd, 2010

In JSF 2.0 <h:link> tags were introduced that allow users to navigate to a JSF page without using a postback request.

For example:


<h:link value="3 Month Subscription" outcome="subscribe" />

would create an HTML link similar to:


<a href="/MyApp/faces/subscribe.xhtml">3 Month Subscription</a>

The value of the “outcome” parameter utilizes JSF 2.0 implicit navigation rules that save you the trouble of defining navigation cases in the faces-config.xml file.

Furthermore query parameters may be added to the links:


<h:link value="3 Month Subscription" outcome="subscribe">
    <f:param name="subscriptionType" value="threeMonth" />
</h:link>

<h:link value="6 Month Subscription" outcome="subscribe">
    <f:param name="subscriptionType" value="sixMonth" />
</h:link>

The links would look like this:


<a href="/MyApp/faces/subscribe.xhtml?subscriptionType=threeMonth">3 Month Subscription</a>
<a href="/MyApp/faces/subscribe.xhtml?subscriptionType=sixMonth">6 Month Subscription</a>

This way we are able to preset the subscription type field on the subscribe.xhtml page. In subscribe.xhtml there might be the following Radio Buttons:


<h:selectOneRadio label="Subscription Type" value="#{BackingBean.subscriptionType}" id="subscriptionType">
    <f:selectItem itemLabel="3 Month Subscription" itemValue="threeMonth" />
    <f:selectItem itemLabel="6 Month Subscription" itemValue="sixMonth" />
</h:selectOneRadio>

Instead of representing the subscription type value as radio buttons you could use any other input component including for example a hidden field.

In order for the radio button to be selected upon loading the subscribe.xhtml page you must add the following annotation to the subscriptionType field in the corresponding JSF managed bean:


[...]
@ManagedProperty(value="#{param.subscriptionType}")
private String subscriptionType;
[...]

Differences between TopLink and EclipseLink

Monday, March 22nd, 2010

The default persistence manager in Netbeans Release 6.8 has changed from TopLink to EclipseLink and I will list error messages and differences that I find as I go along.

1.
ErrorMessage

Exception [EclipseLink-8034] (Eclipse Persistence Services - 2.0.0.v20091127-r5931): org.eclipse.persistence.exceptions.JPQLException
Exception Description: Error compiling the query [findUserByEmail: SELECT u FROM theuser u WHERE u.email = :email]. Unknown entity type [theuser].
at org.eclipse.persistence.exceptions.JPQLException.entityTypeNotFound(JPQLException.java:483)

Solution
EclipseLink is case sensitive. If your entity is named “TheUser” (yes, it is a dumm name for an entity) your named query should be:
@NamedQueries({
@NamedQuery(
name="findUserByEmail",
query="SELECT u FROM TheUser u WHERE u.email = :email"
)
})

and not ...SELECT u FROM theuser....

Preview Release of JavaFX Composer

Thursday, December 17th, 2009

Just this week marked the release of Netbeans 6.8. Another release that has been worth waiting for with many great new features including full support of Java EE 6.

One of the things that followed after the release was the announcement in Netbeans newsletter Issue # 420 – Dec 15, 2009 that a preview release of JavaFX Composer was made. The release has been made very silently since none of the other major JavaFX blogs we are following has picked up the news. JavaFX Composer is a visual design tool or RAD (rapid application development) tool that has been much anticipated and will make the development of “business” applications using JavaFX more compelling for businesses.

We are very excited about the release and our first impression is very good. We hope to give the composer a more thorough test ride soon.

The JavaFX Composer is a Netbeans plugin and you can get it like this:

“The JavaFX Composer is a preview release and is available for NetBeans IDE 6.8 as a plugin from the NetBeans Update Center. (From the NetBeans IDE, go to Tools –> Plugins –> Available Plugins –> JavaFX.) ” (source Netbeans newsletter issue #420)

More information can be found here.

The other tool Sun is working on is the JavaFX Authoring Tool where no release date has yet been made public.

How to use Inkscape’s new JavaFX export functionality

Wednesday, December 16th, 2009

With the release of Inkscape 0.47, Inkscape now offers its users to save their work as JavaFX *.fx files. This is how it works for you.
Create a graphic in Inkscape for example:

img in inkscape

Choose File -> Save As… -> Select file type as JavaFX *.fx

The file name you have chosen for your JavaFX file is the name of the JavaFX class. We named our file MyShape.fx
So in a JavaFX Project you can call new MyShape and your graphic should appear.

img in javafx

Unfortunately there were three bugs that we encountered in this simple example.
Number one, the text of our Inkscape drawing does not show up in the JavaFX export (Inkscape Bug 489364).

Number two, in the create Method of the JavaFX export file a method named path4117-5() is called (Inkscape Bug 439270). This is not only incorrect syntax but the method does not exist. It was called path4117_5() and changes had to be made to the JavaFX file.

And number three, as you can see the stroke width of the line is not the same. Going into the code you can see that the width is set to 0.0 in Inkscape’s JavaFX file, when in fact it should be set to 6.0. (I filed bug 497416).

If you would like to avoid names such as path4117 etc. in your JavaFX files, select any one of your objects in Inkscape, press the right mouse button and select “object properties”. Here you can change the Id to something that is easier to remember.

There are of course more things to discover in collaboratively working with JavaFX and Inkscape, some of which we might focus on in the near future.

While these three bugs are unfortunate, they will probably be easy to resolve. Let us also not forget, that JavaFX support is new to Inkscape. What counts for now is that it is great that Inkscape offers an open source alternative to creating graphics for JavaFX.

Starting GNOME Development – Starting your own project

Tuesday, February 17th, 2009

I had already posted a *very* quick start guide on how to start working on existing GNOME projects. Today I will focus on how to start your own GNOME/GTK+ project.

What programming language do I use?

The mother of all questions. While you may know that you want to do GNOME/GTK+ development the choice of languages with excellent bindings is sheer overwhelming. Unfortunately it seems that picking a language and sticking with it always involves a trade off. Anyway here are a few thoughts about picking the right language just in case you can’t make the choice on your own.

C is the language most of GNOME is written in. If you want to later contribute to core GNOME projects, C is worth learning and there is no better way than writing your own little project. The drawback is the amount of boilerplate code, the need for memory management and if you come from another language the need not only to familiarize yourself with GTK+, but also with a new programming language.

Python, C#, Java, Perl, C++ all of these languages have official GNOME bindings making all of these languages a good choice. If you come from one of these languages you will probably be up and running quite quickly. Python and pygtk are widely used in GTK+ development. C# runtime is developed in the mono project and is used in several more recent GNOME projects. Java has the benefit of running on top of the very fast Java Virtual Machine (JVM). The documentation of the Java GNOME bindings are not up to par with the other languages, but that is supposed to change in the near term and might be something you can help with? The Perl GTK+ project is gtk2-perl and C++’s project is gtkmm.

Other languages. Check the official GNOME bindings for any of the other languages. You will probably do just fine using any of these if you already know the language.

Then there isĀ Vala. Vala is a new high level language that compiles into native C code and thus will be as fast or at least almost as fast as apps written in C. Vala can therefore be used to write core GNOME libraries and apps because it does not depend on a runtime like Java, C# and Python for example do. The irc channel is always crowded so there seems to be quite some interesst in this language. Is it the future of GNOME development? I don’t know, but you should keep an eye on the project.

Summing up I would suggest to be very pragmatic with your choice. Stick to what you know and you will find success a lot quicker. After all the many GTK+ bindings have the intention of letting programmers program with whatever language they like most. If you learned the basics of GTK+ and have written your first little apps take a look at other languages. Each language has its own strengths and merits and soon you might choose a different language depending on the type of GTK+ project you are writing.

If you are new to programming and do not yet have a preferred programming language I would suggest getting started with either Python, Java or C# (I might give a slight edge to python).

Use Glade for GUI development?

So you have chosen a programming language. Now do I hand code my GUIs or do I use Glade as a graphical user interface builder? My advice would be to get started by hand coding a few of the basic widgets. Seeing the code and seeing how it works gives you a much better understanding of the GTK+ widgets and programming principles. Once you have a basic understanding of events, signals, arranging widgets etc. go ahead and start learning to use glade. For most straightforward GUIs this tool can save you a tremendous amount of time. The place to start learning to use glade is here.

I heard something about GtkBuilder instead of libglade?

Everything you need to know about this can be read Micah Carrick’s blog.

What tutorials are worth following?

  1. The best tutorial I have found to get you started quickly is Micah Carrick’s tutorial.
  2. Then there is the book Foundations of GTK+ development. So far I think it is a good resource and I will post a detailed review sometime in the near future. The only apparent problem is that the book focuses only on the C programming language and that will not be of great use if you do not plan to write your code in C.
  3. The official GTK+ tutorial is lengthy but a good starting point. Programming language is once again C.
  4. For python there is the pygtk tutorial.
  5. For Java there is this tutorial which gives you a quick overview of how to develop with javagnome bindings including using glade.
  6. For Vala there is the Vala tutorial.
  7. For C# and GTK# there are a whole bunch of articles and tutorials.