Marrying JSF with Scala - Part2

View Controllers and Navigation

While part1 showed us how we can do managed beans in Javascript, we now will go a little bit deeper. In this part we will talk about view controllers and navigation implemented in Scala.

Short Introduction to ViewControllers

While JSF does not know the ViewController pattern, for JSF is everything a managed bean, it makes sense to name a certain set of managed beans ViewControllers.
Per definition in JSF a ViewController is a managed bean, which deals directly with the user interface interaction from the backend.

Such interactions are

• Actions
• Events
• Listeners
  
• 
  
• etc...

A typical plain Java Viewcontroller

So a typical Java ViewController in a plain JSF environment looks like following.
Everyone who has programmed JSF is familiar with those patterns.
 
Sidenote: there are frameworks which add dedicated view controllers with dedicated callbacks for postCreate, preRender
 

ViewController in Scala

The question now is, how does this look in Scala. Again, this code is somewhat smaller thanks to the absence of setters and getters. However the structure of this class is not 1:1 translatable to Java due to following new construct:  
So what is this object all about?
Scala does neither know static classes nor variables, instead it has singletons in its language core as companion pattern to classes. If a construct is defined via object instead of class, then the resulting object is a singleton. To make the code tighter, Scala also allows imports everywhere. Members of singletons can be imported simply by import <Singleton>._ so that we can call them directly in our code.
If you notice in our action callbacks we return the members of the singleton directly, like we would do it with static variables in Java.

MyFaces Codi Typesave Navigation

MyFaces Codi has an interesting feature, the so called typesave implicit navigation.

While JSF2 already eased the lives of developers by introducing an implicit navigation (aka return value of an action == page name if no navigation rule is given), MyFaces Codi goes one step further.
It maps pages to classes (page name must be the class name) and it allows the grouping of navigation elements in wrapper classes (follow this link for further reference).

While in my personal opinion, the class based navigation alone, it really shines once you add advanced codi features to it like the security handling or the View Controller extensions.
(For more Information please consult the MyFaces Codi documentation) 

Here is a small example: This is a very basic example of two navigation cases

• the first one points to /Wizard/Page1
• the second one points to /Wizard/Page2

However to map this to scala we face a set of problems

1. We don't have interfaces, we have mixins, but they do not map straight to the structures we need
2. the interface classes are the same problem as the interfaces

So we have to find structures which Codi can follow but are buildable in Scala. Here we have the same example in Scala: Again we are able to map everything into singletons so we work with a set of objects instead of interfaces and interface classes.

That sums up part2 for now

Next week, I will talk about how to leverage Scalas very powerful trait feature to isolate common behavior.

Marrying JSF with Scala - Part1

 This is the first part of a mulitpart blogpost on how to marry JSF with Scala.

Why Scala? Java is fine

My personal opinion is, having done programs in many languages, that Scala is a huge step up from Java complexity-wise and many things are corner case fillers which probably could have been left out with a more lenient approach.
Nevertheless Scala has lots of merits as well.

The code reduction compared to Java on the average is 30-50% less thanks to better property handling and other things like closures.
The speed if touched right is about the same as Java (one of the complaints about groovy).
However, if you want to apply Scala you seriously have to touch it the way you would touch C++, make up your mind on what part of the language you really use and only touch others in rare cases.

But lets stop the criticism here. Scala has lots of merits especially for JSF:

• Absence of setters and getters
• Tight integration with Java
• Isolation of common constraints via Mixins instead of base classes
• Same or almost the same performance as java
• Closures for things like iteration
• etc...

So lets dig into JSF and Scala

Part 1, Managed Beans

The possible easiest entry into combining Scala and JSF is to create a managed bean. Every managed bean in JSF is a pojo with a handful of setters and getters. (and more depending on your functionality)
It probably is the easiest artifact within the JSF stack you can get.

Let us have a look at a simple Java managed bean:


The same now would be coded in Scala


Note for the people who are familiar with Scala, we took two assumptions here, first we are using for familiarity
reasons the Java mutable LinkedList and secondly we use BeanProperties
(we could resolve that with our own el resolver as well)


This is tightlier written, but what about data encapsulation what about setters and getters?
Scala follows a different route for data encapsulation. You can set properties but usually the data is public until you have overrides which cause the data encapsulation without any further code interference.

Also one thing noticeable is, that the implements Serializable has been replaced by a @serializable annotation. The rest of the annotations is applied as is.

So what about this @BeanProperty?

This is a special Scala annotation which tells the compiler to encapsulate the property and generate setters and getters for it.

I want to use CDI instead of ManagedBeans

CDI has been the new kid on the block and given that bigger projects nowadays either use Spring or CDI it makes sense to cover the CDI integration here as well.
To sum the CDI and Scala situation regarding managed beans, it is as seamless as it is with pure managed beans.

Here is an example:


Of course you still can use @Inject and other CDI constructs as well.

@BeanProperties is this really needed?

As you have seen @BeanProperties produces the connection between our properties and the EL by encapsulating the property and providing Java like setters and getters.
This is very inelegant, first of all, because to access those properties, you have to use the setters and getters on the Scala side as well, and the code is convoluted with annotations.

Wouldn't it be nice to simply have something like:


This works as expected, even the EL will pick up all properties, thanks to Scalas public per default convention. However we now face a problem, once we want to encapsulate for instance val1. If we now would make it private or protected the code definitely would be broken and the EL would not pick it up anymore. As long as you stay in Scala, you can use Scala properties, however the EL is implemented in Java and expects Java setters and getters.

So to make the EL scala aware we have to roll out a binding solution, but first, lets talk about Scala properties.

Scala properties are a different convention. From outside they are invisible by default but they still implement full isolation.

So, code like myobj.myprop = 1 still would be myobj.myprop = 1 after the isolation has been added.

So how do we do it?

• the def val1: Int = _val1 is basically our new getter replacing our old val1 for read access
• def val1_$eq (val1: Int) is basically a convention to open val1 for write access via the = operator.

This works within Scala seamlessly and for orm frameworks as well as long as they know the Scala convention (most do by now via plugins). But on the Java side you have to call those methods directly via <methodName> and <methodName>_eq.
The last remaining open problem is the Expression Language. The EL relies on setters and getters for accessing the properties.

Thankfully there is a way to override the ELs handling via a custom resolver tailored for Scala. Now this code would override the scope of this blog, but you can download the sources for this EL resolver as Maven project from https://github.com/werpu/scalaelresolver
(NOTE: You have to follow the included readme.txt for your own project integration)

End of Part1

We now have reached the end of part1. The next part will be about the ViewController patterns. Page navigation Codi style in Scala, and what we can do with Scala traits in a JSF context. So stay tuned.

Extensive German JSF Tutorial

If you are in need for an extensive JSF Tutorial and you can speak or read german, than head over to following site http://jsfatwork.irian.at. This is probably the most comprehensive JSF guide you can get for free currently.

Dynamic data definitions the Groovy way

Hello everyone did you have ever had the need to define some data which quickly can be processed? Well there are myriads of ways. There is xml, and you can roll your own parser, you can use property files. But there is another way. You could do it in a dynamic scripting language.

Well we have Groovy and we could use the Groovy builders as shown here. The Problem with the builders is that you might lose some realtime syntax checking, some tools already have. I want to talk about a different way to describe data. A combination of properties and closures to keep the syntax lean. Lets have a look at an example.



Normally we would have to generate the class and set the properties or we would have to define constructors with property lists. There is another way, we can use closures to set the properties dynamically at object creation



What we do here is to generate a new object and dynamically set helloWorld which has a predefined value of "helloworld" to add. Another way to do the same would be following:



Or like following:



Same result different angle to the approach. What we do here is following we use the internal map semantics groovy uses to store properties to set the value of helloWorld to a new value. In the first example we do it explicitely in the second one via dynamic parameter maps for the constructor. Both cases would result in the same result! Lets have a look on how compact this approach is:



Now think how much more code you would have in xml or how much more effort this would be by rolling your own data definition language. The good thing is you can set your properties to predefined defaults and then use the closures to override the values you want to change. The best thing however is you can use all this seamlessly from java. A Java Class simply would have to call the setters and getters of the properties of the generated objects to access those values! The groovy compiler takes care of the rest!

Apache MyFaces jsf.js queue control

Introduction

As some people might have noticed our javascripts are bigger than Mojarras. There is a reason for it, besides our internal structures completely different we have a set of extensions which yet have to make it into the official spec (all of it has been donated to the EG)

I already wrote about the fileupload via ajax, and again, I have to warn, if you use that stuff you are bound to MyFaces.

But nevertheless, partial page submit and queue control are two important features which have been enabled since 2.0.1:

Queue Control, what is it?

The official spec enforces following behavior: if you submit an Ajax post it is either sent directly if no other submit is running or enqueued until the running ajax submit has terminated and then the submit is issued.

Now this causes following problems

The typical fast typing Ajax input.

Here typing happens on the fly and a load of submits are issued, they are either queued or simply sent to the server causing constant loads.

The long running Request

Here a request hangs for a longer period of time, filling the client queue.

For those two szenarios we introduced (thanks to the j4fryguys Ganesh and Alax who donated the code), advanced queue control.

Here is the deal on how to use it (and again the obligatory you bind yourself to myfaces warning)

First a short introduction to our configuration system: We are very modular all layers are bound late via configuration and also vital parts of the system can be replaced without digging into the code internals that way, this configuration system also can be used to override certain default behavior.
Now there are to ways to override the configuration, you can do it globally under the myfaces.config namespace or locally by pushing another additional set of parameters in the options map under myfaces (example below)

An example for a global configuration for instance is:


an example for a local configuration override for a single request is:


Now we have following possibilities in our codebase:

timeout: describes a value of miliseconds upon the current request should be terminated for good and the next one be issued

delay: describes a delay period where the system waits for the next input before issuing the submitted. If an input is sent before the delay period is over the old request is canceled upfront and the new one is enqueued delayed.

queuesize: This limits the queue size of the request queue to the specified number of elements, if the queue is bigger than what is provided older elements are dropped until the queue size is fulfilled. If issued locally the reduction is only done temporarily.

For a typical ajax scenario following might be a viable approach:

Second Part, PPS

This solves following scenario, per spec definition the entire form passed down must be submitted at each Ajax scenario. Often this is unnecessary, especially if you only execute parts of the subtree. Unnecessary data is passed down and if you have something like a textfield in the form then it is even heavy on the server.

There pps helps. With pps you will just pass what is needed to be executed, you also can put the execute on a parent node and it determines which childs have to be passed down the execution chain and it only submits the parameters it really needs to pass down.

(note this does not work in the ajax fileupload case)

Here is an example on how to use it:


again this also can be set globally via
myfaces.config.pps = true

Hello and Welcome

Hello and welcome, I have moved my blog now from jroller to Blogspot.

As first entry I want to show how to roll an testing ssl connector from Maven 3 with the Jetty Maven Plugin:

Here is the code:



As you can see it comes down to two things, generate a temporary public key for jetty in the build and then use the ssl connectivity in the jetty plugin to open the ssl port with the generated key.

If you use an older combination, you can use following code as blueprint:
(note the keystore setup stays the same)