Lo step “Get Data From XML” di Kettle è decisamente versatile: ci permette, infatti, non solo di leggere e trasformare un file XML, ma ci consente anche di effettuare le medesime operazioni sfruttando un campo di una tabella, che usiamo come input. Come fare? Innanzitutto, dovremo necessariamente alimentare il “Get Data From XML” con un “Table Input”:
Questa volta, la configurazione dello step sarà un po’ più complessa rispetto alla normale amministrazione, in cui viene alimentato da un file: in particolare, con questo disegno, non sarà infatti possibile che il sistema intuisca la struttura XPath che stiamo leggendo.
Per cui, dovremo prima specificare il campo di origine XML:
In seguito, andremo a definire il loop dell’XPath:
E, infine, i campi che andremo a generare tramite la denormalizzazione.
Anche in questo caso, non potremo sfruttare l’intelligenza del sistema nella definizione di questi ultimi (tramite la funzione “Preleva Campi”), ma dovremo specificarli manualmente.
Notate che, allo stesso modo, non avremo la possibilità di usufruire della funzione di anteprima contestualmente allo step, e non potremo fare altro che, prima, confermare le modifiche allo step, e, in un secondo momento, lanciare l’anteprima della trasformazione.
Un’ultima nota: personalmente, su Postgres, definire il datatype nel medesimo step (“Get Data From XML”) mi ha creato problemi, per cui, in un primo tempo, ho definito tutti i campi come String. In seguito, aggiungendo al flusso lo step “Select Values”, ho potuto alterare i datatype.
Developing portlets with Grails is great but there are still some issue to solve. Today I would talk about two problems related to GORM and Hibernate.
First: some GORM stuff works, while some others don’t and cause exceptions about the Hibernate session not being found.
For example, if we have a domain class like this:
class Car {
Manufacturer manufacturer
Engine engine
Tyre tyres
Integer seats
}
calling
Car.get(id)
will works, but
Car.findByManufacturer()
won’t.
There are also different behaviours by calling this methods in the render phase or in the action phase.
Second: lazy load doesn’t work in .gsp views and portlet classes.
So writing
<label> ${car.manufacturer.name} </label>
cause an exception
org.codehaus.groovy.runtime.InvokerInvocationException: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
and, of course, the portal isn’t able to render the page.
In summary, it turns out the problem is that the OpenSessionInViewFilter doesn’t work properly in a portlet environment.
I faced this problem a few days ago and I found this solution:
first of all, I suggest to put the code that use GORM in a service class and call the service method from the portlet class. That’s because service classes can get the hibernate session with no problems and use all of the cool dynamic methods for domain classes.
Then, that service method must use domain class dynamic methods with the fetch argument set to “eager”, so the model will be fully loaded.
Your renderView closure in the portlet class will look like this:
def renderView = {
def cars = carService.loadAllCars()
['cars' : cars]
}
and here is the service method:
def loadAllCars() {
Car.findAll([fetch:[manufacturer:"eager", engine:"eager", tyres:"eager"]])
}
Of course setting the fetch mode to eager leads into using fewer queries than the lazy mode, because the Car model and its associations will be loaded all at once. However, if you have many associations loaded with eager fetching you will have a lots of objects loaded into memory, so be careful and pay attention while designing your service methods.
This post is the first (I hope) of a series about my adventure in Clojure land.
Being Clojure hosted on the JVM, it’s a natural choice for a Java developer wanting to study and learn functional languages.
A simple exercise
I started with a simple exercise: add all the natural numbers between 1 and 100 which are multiple of 5 or 7
; Add all the natural numbers below 100 that are multiples of 5 or 7. (def r (range 1 100))
The lines starting with ; are comments.
The second line creates a range of numbers, starting from 1 to 100, and assigns the sequence to the symbol r.
I then defined a function which, given a number, returns true if the number is divisible by 5 or 7.
(defn divisibile [x]
(if (== 0 (mod x 5)) true
(if (== 0 (mod x 7)) true false)))
The following statement filters the range returning a list of the values which are divisible by 5 or 7.
(def validValues (filter #(divisibile %) r))
Then I sum the validValues, using the reduce function; int the following statement it applies the + operator to the elements of the sequence: if the sequence is (a b c), the expression returns (a+b)+c
(def tot (reduce + validValues)) ; print the result (println tot)
I’m an absolute beginner in clojure and functional programming, so I would be happy to receive comments or suggestions. Thanks!
Enrico
Problem:
Create a custom property editor between Model and View to show it as we need. (example: we wanted to change how shows the java Date.class in a view, from default format ‘yyyy-MM-dd HH:mm:ss.S’ to ‘dd-MM-yyyy’).
Solution:
There are 2 solutions which I can see now. The first one is, when every time we show a Date object, format it using a java DateFormat implement and show it. But the pretty solution is the second one, create a custom property editor to show it. So you don’t have to modify every date field that views show. To do that you have to create your property editor by implementing PropertyEditor and property editor registrar by implementing PropertyEditorRegistrar to register your property editor.
For example we created our ‘CustomPropertyEditorRegistrar’ as property editor register and we used spring’s CustomDateEditor as a property editor:
import java.util.Date
import java.text.SimpleDateFormat
import org.springframework.beans.propertyeditors.CustomDateEditor
import org.springframework.beans.PropertyEditorRegistrar
import org.springframework.beans.PropertyEditorRegistry
public class CustomPropertyEditorRegistrar implements PropertyEditorRegistrar {
public void registerCustomEditors(PropertyEditorRegistry registry) {
registry.registerCustomEditor(Date.class, new CustomDateEditor(new SimpleDateFormat("dd-MM-yyyy"), true));
}
}
And finally you must add your custom property editor registrar to grails resources (‘grails-app/config/spring/resources.groovy’):
beans = {
customPropertyEditorRegistrar(CustomPropertyEditorRegistrar)
}
That’s all!
When writing a groovy test case you almost want to be concise and expressive… next time you’ll see the test you must undestand it quickly.
Here’s a small tip to enhance test writing.
Having :
def car = new Car() def jack = new People() def tom = new Cat();
Instead of writing somethings like :
car.addPeople ( people ) car.addCat ( tom )
it’s really simpler to write:
car += jack car += tom
To achieve this it’s as easy as writing a plus method in you model object.
public Object plus(Object o) {
if(o instanceof People) {
this.addPeople((People)o);
}
if(o instanceof Cat) {
this.addCat((Cat)o);
}
return this;
}
Just remember this method must return this.