The beauty of the State (Pattern)

Ok, let's talk about design, please.

First, recall what said in my previous post:

Say the boost() method, depending on the GearType, must do the following:

• Decreasing Car fuelQuantity and oilQuantity.


• Calling changeGear() on TransmissionGear

How would you do this?

For a moment, I'll talk about the straightforward way: if you have a boost() method on the Car object, which must behave differently depending upon a property of some associated object, simply code a sequence of if statements upon this property.
So, if GearType is FIRST, change fuelQuantity and oilQuantity accordingly and change gear to SECOND; if it is SECOND, change them in a different way and change gear to THIRD; and so on.

You can code this in minutes, but if you do so you'll have a lot of problems.
Your code has a lot of if statements, is not so object oriented and is hard to read.
Moreover, the biggest problem is that if you must add another gear, you'll have to directly modify the boost() method for add another if!
You are changing some code that actually works ... what happens if your change breaks something?!

The best would be to completely isolate the various boost() algorithms, and the adding of another gear, that is, another algorithm for boost().

A good way to do so is applying the State design pattern.

You'll have to simply:

1. Encapsulate the Car properties, changed by the boost() method, into a value object (LiquidQuantity, sorry for the stupid name) : this prevents from directly changing Car properties.
   Note that this is an optional step, because you could simply insert two getters/setters into the Car class, but in this case I'd suggest you to make this
   setters package-protected.


2. Create a "state" class for every gear type, implementing a common interface (GearState): it represents the changing state.


3. Implement, in every GearState, a boost() and a changeGear() method: the former must implement the algorithm which changes the LiquidQuantity, the latter must determine the next gear.


4. Associate the TransmissionGear with all GearState objects through a Map, whose keys are the various GearType: doing so, the TransmissionGear can access the GearState using its GearType property, representing the current gear.


5. Implement a boost() method in TransmissionGear, which delegates to its current GearState for the appropriate boost() and changeGear() behaviour.


6. Implement the boost() method in Car, making a call to the boost() method on TransmissionGear.

This is a class diagram with some meaningful comments and Java code snippets:



Maybe I should show you an interaction diagram, too, but for now I'm too lazy, maybe in the next post if you care ;)

Using the state pattern, so, you can clearly separate the behaviour that changes in conjunction with the state of some object, and add another state, with another behaviour, without affecting old code: in our example, simply implement another GearState and add it to the TransmissionGear map.
Moreover, the state changing is also absolutely transparent.

This, obviously, at the cost of some more class and some more dependency between classes, but I think that benefits overcome.

As always, have a good design!

Object Challenge

Challenges are always something people love to face ..... if you want an example, think to Sudoku success!!!
So, I want to submit you a challenge based on some object oriented crunches.
Give me your attention for some minutes, if you care, or if you don't have something better to do.

Say you have a Car object in your business domain.
It has state and behaviour, so no, it is not an anemic business object.
Say you have, besides all other components, a TransmissionGear which is a part of your car.
It has its good state and behaviour, in particular it has a GearType attribute which defines the actual gear, and a changeGear() method for changing gear.
Car, on its side, has a boost() method which interacts with the TransmissionGear and whose behaviour depends on the GearType.
Take a look at this diagram:



Say the boost() method, depending on the GearType, must do the following:

• Decreasing Car fuelQuantity and oilQuantity.


• Calling changeGear() on TransmissionGear

How would you do this?

There's no best method, but surely there's a method better than another one.

If you care, leave a short comment, or simply think.
Think about this.

I'll give you my solution in one of my next posts!

Unit testing with the Spring Framework, Part 2

In one of my old posts, Unit testing DAO classes in the Spring Framework, I talked about how to test Hibernate based DAO classes implemented with the HibernateDAOSupport Spring template.

However, inspired by a Matt Raible blog post, I've recently started to use the AbstractTransactionalDataSourceSpringContextTests Spring class.

It's a long time since I want to post about this very interesting piece of thing.

This class provides an easy way to do unit, but I'd better say integration, tests over your Spring managed business objects and services, importing your Spring configuration, loading an appropriate Spring application context based on it, and wrapping your test methods each in a separated transaction which will be rolled back at the end of the method, avoiding so to insert test data into your database tables.

This sounds very good, because you don't have to manually configure Hibernate (it will be configured in your Spring application context), nor to manually manage transactions, nor to worry about unwanted test data!!!

So, you will simply have to:

• Subclass AbstractTransactionalDataSourceSpringContextTests.
  


• Overwrite the getConfigLocations() method, which must return an array of String objects, containing the location of your Spring configuration files.
  You will be able to access your application context through the applicationContext instance variable.
  


• Write your test methods!!!!!
  

In your test methods, you can use all normal JUnit assert methods.

Moreover, you will be able to do a lot of other cool things, like accessing a jdbcTemplate variable for making SQL queries, committing transactions instead of rolling them back, or making special setup operations before every test method in the same context of its transaction or in another one.

Take a look at its javadoc.

Good testing!

Strange side effects of White Phosphorus (WP)

From an interview to Lieutenant Colonel Steve Boylan, spokesperson for the U.S. military in Iraq, Jeff Englehart, former army Specialist in Iraq, and Maurizio Torrealta, News Editor for the Italian television RAI and co-producer of the film "Fallujah: The Hidden Massacre":


LT. COL. STEVE BOYLAN: We have used it in the past. It is a perfectly legal weapon to use.

AMY GOODMAN: Maurizio Torrealta, news editor for the Italian state broadcaster, RAI 24. Your response?

MAURIZIO TORREALTA: Well, the United States, as the UK and Italy, signed the convention about prohibition of chemical weapons. And the convention define precisely that what make forbidden an agent, a chemical agent, is not the chemical agent itself. Because as Lieutenant said, the white phosphorus can be used to light the scene of a battle. And in that case, it's acceptable. But what make a chemical agent forbidden is the use that is done with it. If you use white phosphorus to kill the people, to burn and to block them, people and animals, even animals say the convention that we all sign, Italy, United States and UK, this is a forbidden chemical agent.

And we are full of picture that show bodies of young people, of children, of women which have strange -- particular, they are dead with a big corruption of the skin and show even the bone. And the clothes are intact, untouched. And that shows there has been an aggressive agent like white phosphorus that has done that. And we have all the number of those bodies and the place where they have been buried. So any international organization that wanted to inquire about that has all the tools and information to do it. And even the witness -- the U.S. military that we interview confirmed that the use of white phosphorus was against the population. And we have even picture of the fact that has been told by the helicopter down to the city, not by the ground up in the air to light the scene. Also the images, they spoke by themselves.

AMY GOODMAN: Jeff Englehart, you are the Specialist -- former U.S. Specialist in the Army, a member now speaking out against the war. You are interviewed in this documentary explaining how white phosphorus was used in Fallujah. Can you tell us more?

JEFF ENGLEHART: Oh, yeah. I mean, I definitely heard it being called for. And I even talked to reconnaissance scouts after the siege, and they said they had actually called for it. The Pentagon spokesperson says that they use this for concealment, or some sources say they use it for illumination. But, I mean, I think that's ridiculous, because we would use -- just based on my training as a reconnaissance scout myself, we would use illumination separately, as it’s on exclusive ground. Since my training, we were taught that white phosphorus is used for troops out in the open or to destroy equipment and that it burns and that the only way to prevent the burning is to douse it with wet mud.

To me, it's definitely a chemical weapon in the fact that it burns, and it burns indiscriminately. In fact, the use of white phosphorus violates the Geneva protocol for the prohibition of use in war of asphyxiating, poisonous or other gases and bacterial methods of warfare. So, I mean, even if the Geneva Protocol says it's illegal, I don't see how we're able to use it and then say that it's used for our own cover or illumination, when it actually could hurt our own troops. So I just think that, from the very top, the big problem with this war is that from the very top to the lowest level soldier, everyone's being lied to. And then the news gets gentrified by the mass media to make it sound like, ‘Oh, well, white phosphorus is a good weapon that we can use to help spot targets,’ when it's actually designed to burn its victims.

How good is White Phosphorus (WP)

From an interview to Lieutenant Colonel Steve Boylan, spokesperson for the U.S. military in Iraq:


AMY GOODMAN: So are you confirming that you used white phosphorus in Fallujah, but saying that it's simply not illegal?

LT. COL. STEVE BOYLAN: White phosphorus has been used. I do not recall it was used as an offensive weapon. White phosphorus is used for marking targets for both air and ground forces. White phosphorus is used to destroy equipment and other types of things. It is used to destroy weapons caches. And it is used to produce a white smoke which can obscure the enemy's vision of what we are doing.

AMY GOODMAN: And you're using it in Iraq?

LT. COL. STEVE BOYLAN: We have used it in the past. It is a perfectly legal weapon to use.

How to survive White Phosphorus (WP) ...

... if you are ACCIDENTALLY hit by WP particles during a military action.

From GlobalSecurity.org (see here):

If burning particles of WP strike and stick to the clothing, take off the contaminated clothing quickly before the WP burns through to the skin. Remove quickly all clothing affected by phosphorus to prevent phosphorus burning through to skin. If this is impossible, plunge skin or clothing affected by phosphorus in cold water or moisten strongly to extinguish or prevent fire. Then immediately remove affected clothing and rinse affected skin areas with cold sodium bicarbonate solution or with cold water. Moisten skin and remove visible phosphorus (preferably under water) with squared object (knife-back etc.) or tweezers. Do not touch phosphorus with fingers! Throw removed phosphorus or clothing affected by phosphorus into water or allow to bum in suitable location. Cover phosphorus burns with moist dressing and keep moist to prevent renewed inflammation. It is neccessary to dress white phosphorus-injured patients with saline-soaked dressings to prevent reignition of the phosphorus by contact with the air.

Some nations recommend washing the skin with a 0.5-2.0% copper sulphate solution or a copper sulphate impregnated pad. Wounds may be rinsed with a 0.1%-0.2% copper sulphate solution, if available. Dark coloured deposits may be removed with forceps. Prevent prolonged contact of any copper sulphate preparations with the tissues by prompt, copious flushing with water or saline, as there is a definite danger of copper poisoning. It may be necessary to repeat the first aid measures to completely remove all phosphorus.

White Phosphorus (WP)

From GlobalSecurity.org (see here):

WP is a colorless to yellow translucent wax-like substance with a pungent, garlic-like smell. The form used by the military is highly energetic (active) and ignites once it is exposed to oxygen. White phosphorus is a pyrophoric material, that is, it is spontaneously flammable.

White phosphorus results in painful chemical burn injuries. The resultant burn typically appears as a necrotic area with a yellowish color and characteristic garliclike odor.

Incandescent particles of WP may produce extensive burns. Phosphorus burns on the skin are deep and painful; a firm eschar is produced and is surrounded by vesiculation. The burns usually are multiple, deep, and variable in size. The solid in the eye produces severe injury. The particles continue to burn unless deprived of atmospheric oxygen. Contact with these particles can cause local burns. These weapons are particularly nasty because white phosphorus continues to burn until it disappears. If service members are hit by pieces of white phosphorus, it could burn right down to the bone. Burns usually are limited to areas of exposed skin (upper extremities, face). Burns frequently are second and third degree because of the rapid ignition and highly lipophilic properties of white phosphorus.

Your Face Tomorrow

Sometimes I wonder if my life would be a lot better and easier if I didn't know anything.
Anything about people, I mean.
Anything about my friends, my family, even about me, even about unknown people.

This is a strange thing to tell and I don't know if anything of you can understand, but what I think is that people, but I'd rather better say humans, rarely know by itself what they really are and want.
They often build castles and paint pictures of what they would like to be, of what life should be, but this is not reality.
Reality is never clear.

And being unclear in respect of yourself, how can you be clear in respect of other people?

So, I'll never know how your face will look tomorrow, and probably will never know also mine.
I'll never know my friends, my enemies, what is good and what is bad, so the only thing we have to do is trust or don't trust, and left all to time and destiny, which I think, time and destiny, are the same.

This is what people do, this is what people is used to do and want to do, and this is what permit them to stay safe.
Shut your eyes, your mouth, your ears, and be safe.
Because knowing something about you, about people, about life, something that you'd never want to know, really hurts.

I can assure you, waking up some day, discovering that you are not what you think and what you'd like to be, and that people living with you is not what appear to you ... really, really, hurts.

Knowing that your life is somewhat predictable, at least that you could predict what will be good or bad, could kill you, because this would force you to confront life face by face, and would revoke the possibility to say: "I didn't know, I could never have predicted this."

Knowing is responsability.

So, "we love to throw away our shield, marching mild and waving our spear like an ornament".

--

Inspired by Your Face Tomorrow - Fever and Spear, a novel by Javier Marias.

The importance of being extremely built

Ok, as said in my last post, daily builds are good, but what is better?

Like pointed out by my colleague Ugo Cei, like recommended by XP practises, and like well explained here by Martin Fowler, it is better and better to install a Continuous Integration System, in order to go through the "checkout / build / test" process in a fully automated way and many times per day, avoiding the so called "integration hell".

In these days I wanna put my eyes over these open source products for continuous integration:

• Apache Continuum


• Apache Gump


• Cruise Control

I'll let you know, so stay tuned.

The importance of being daily built.

Yesterday I was reading "The Joel Test: 12 Steps to Better Code" : I had already read that article, but yesterday I've given it more than a thought.

Among other things, my mind was caught by the third item : "Do you make daily builds?".

My answer was "no", and my question was: why is this so important?
Yes, I said, they are a good thing and let your team check every day if their new commits do not break old builds ... but I didn't give it much importance.

So, at the end of the day, I committed my daily work, closed orwell (for those who don't know, orwell is my linux box), and came back home.

What happened while coming back, was that ... my mind reminded me that I had forgiven to commit also some libraries needed to compile my daily work!!!
And yes, I actually broke the build ... understanding, by experience, how much daily builds are useful.

So, don't be lazy (yes, I know how much hard may be this ...).... and take one or two minutes, at the end of the day, for daily testing your builds!

JavaZone 2005 ... online!

Hello all,

It has been a long time since the last post, but I'm very busy here at work, so please forgive me!

This is one of these news which really enjoy me ...

Javalobby has published on-line videos and MP3 podcasts of the JavaZone 2005 conferences ... take a look here: http://www.javalobby.org/av/javazone/.

Watching and listening to conferences held by great minds is always awesome, and you can learn a lot of things ... so have fun!

Talking about Cocoon

A recent post on Cocoon dev mailing list, by the Cocoon founder Stefano Mazzocchi, said that "Cocoon is obsolete" ... take a look at the full post for details.

My colleague Ugo Cei, a Cocoon committer, comments on in one of his blogs entry:

For a long time, I’ve been convinced that Cocoon must do less, much less than what it currently does if it wants to thrive and survive. Now it tries to be everything to everyone: a web publishing framework, a web application framework, a portal framework and possibly a business integration platform. I don’t think you can do all of this and at the same time be simple, lightweight and easy.

I'm a new Cocoon developer, but I've been fully involved with it in these last months, and being always in contact with a lot of experienced Cocoon developers I can say that I totally agree with this sort of thoughts.

Adding a lot of features makes maybe the product more powerful, but do we really need certain features used only by, say, a 20 per cent of people?

Like said above by Ugo, it adds a lot of weight and complexity, even if new features are developed in separeted blocks, because developers need to know HOW to manage these blocks, and because, maybe, the whole architecture could be simplified if some rarely used blocks would be discarded, while the most used better "integrated" with Cocoon core components.

And I must say that, with the raising and developing of some new very interesting frameworks, like Ruby on Rails for the non-Java world, or WebWork, or Tapestry, for the Java world, weight and complexity are IMHO a very bad thing.

I think that developer forces should be driven for consolidating and improving Cocoon existing and most used features, rather than adding new ones

These are my 2 cents thoughts about Cocoon present and future.

Photos from a beautiful Calabria

A friend of mine has published a very nice photo set on Focus, an italian magazine.

The subject is a beautiful Calabria which I want to share with you .... here are some links:


http://www.focus.it/community/contr_new.asp?ID=10005


http://www.focus.it/community/contr_new.asp?ID=10009


http://www.focus.it/community/contr_new.asp?ID=10011


And my preferred one:



Take a look and if you want give them a vote!

Congratulations, Mario!

An AJAX office suite

Yes, I say, everyone wants AJAX.

Yes, I say, AJAX usefulness in rich web application development is true: just in these days, for compatibility reasons, I turned off AJAX support from the web project I'm working on, which previously was AJAX-enabled, and I REALLY NOTICE the difference.

And yes, AJAX is very appealing for many developers (like me).

But my mind could never imagine this:



I'm a bit skeptical ... making an office suite is not a joke, in particular if you use javascript ... moreover, I have doubts also about its usefulness over standard office suites and pen drives for storing documents and bringing them around ... but may be interesting!

My best wishes to the development team (hoping will grown) .... have a good luck!

Unit testing DAO classes in the Spring Framework

One of the major claims of the Spring framework is its non-intrusiveness, which, among other things, permits to unit test all classes managed by the Spring container.

So, it is natural that I felt very surprised when yesterday my unit test failed two times while testing a DAO class, based on Hibernate and implemented with the HibernateDaoSupport class provided by Spring.

The first time, my unit test failed because I instantiated my DAO object directly through the no-arg constructor: no one set the Hibernate SessionFactory (normally injected by the Spring container), so this was the problem.
I solved the problem creating a SessionFactory into my unit test, and setting it into the DAO object, as I were the Spring container.

Big surprise, the unit test failed a second time, screaming for no TransactionManager found ... but there was no method for setting such a thing in the DAO object!

So, is the unit testability of Spring managed objects only valid for THAT objects NOT using DAO templates?

The answer is no, you can unit test also them.
In the case of Hibernate, simply create and set by yourself a SessionFactory, like said before, and avoid using Session objects directly into your DAO code.
Just use the template facilities, like the getHibernateTemplate().find(...) methods, or, if you must directly use Query or Criteria APIs, encapsulate the access to the Session in the HibernateCallback class provided by Spring, which automatically manages the session and its transactions.

More and more powerful, more and more lightweight.

Takk...

Simply beautiful.
No other words than these, because no human word can describe what art and creation are.

.... and come back.

There's always a come back, wherever you go you'll always end up coming back to same place, maybe this is our destiny, maybe this is our damnation, maybe our salvation.
It's like the sea ... what if the sea didn't come back towards earth?

So, this is my "come back".

I'm in Rome since Monday, but I've been very busy until today ...
First, my Linux box with Fedora Core 3 started going crazy .... maybe it wanted to stay on holiday? .... no, I must say this, maybe it didn't like some hazardous upgrades, but this is what I most like of Linux, having all the control ... even with the risk of messing up something.
So I had to reinstall Linux, in the form of SuSE Professional 9.3, restore my backups, recreate my development environment, and so on.
Then, I had to take a look at a lot of new mails and news (still in progress)....
And, last but not least, I had to realign myself with the interrupted work ....

Wow ..... very busy.
And I must say that, even if it still needs a lot of work for personalisation, my new SuSE Linux box looks very well and comfortable ..... take a look at this:



I have a lot of ideas and news that I want to share with you ..... as always, I hope to have the time for writing about them, too!

But I'll have.
I'll have.

Going away ....

Tomorrow I'll leave Rome, being away for two weeks.

I'll come back home, my, home, in Messina, Sicily, enjoying my family, my girlfriend, my friends, plus a lot of sun, sea and ... relax.
The right energy for continuing the already started work, and starting new exciting projects ...

I have a lot of ideas .... but they will wait for September.

Now, farewell.

And good night.

Time Out of Joint

"The time is out of joint. O, cursed spite,
That ever I was born to set it right!"

Hamlet, William Shakespeare

When I first read this, suddenly Hermann Hesse's "Steppenwolf" novel came to my mind.

This beautiful (and meaningful) novel talks about the crisis of a 48 year old man, Harry Haller, his conflicts with a world that he views as populated by people living meaningless lives, his frail belief in a "personal" world where knowledge and art are the only worthy things, and his difficult path towards a different (and more real) vision of life.

In the first pages, so, Harry is described as one of that few men who, born in a "wrong" time, like between two different eras, are able to feel all the contradictions and sufferings of their time and world.
A man born in a time out of joint, this makes me think.

But now, seeing what every day happens in our world, today, 15 August 2005, yesterday and tomorrow, I wonder if does really exist a "right" time, opposed to a "wrong" one ...
And I think that maybe it is always wrong, always "out of joint", and never, never, right.
And that only a few persons can feel this, living all the contradictions and sufferings of this condition and consciousness ... like Hamlet, like Harry.

Because there's no hope for the time to be right.

Native support for binding "complex" properties in Cocoon Forms

This is a good news for all those Cocoon guys.

Cocoon Forms has now a "native" support for "complex" properties and JXPath factories.
Simply implement your JXPath factory, as shown in my previous post, and configure it in you binding, without adding any other class.

Take a look at this XML snippet showing a binding example:

<fb:context xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
path="/">

<fb:value id="name" path="name"/>
<fb:value id="surname" path="surname"/>

<fb:context path="residence" factory="com.example.AddressFactory">
<fb:value id="street" path="street"/>
</fb:context>

</fb:context>

As you can see, you must configure your factory class inside a "factory" attribute of an enclosing context element;
enclosed binding elements will automatically use this factory.

For using this new feature, you have to checkout the Cocoon revision 227024 or later, from:

http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/

It is in development, but is almost stable.

Have a nice Cocoon coding!

A strategy for binding "complex" properties in Cocoon Forms

First, a short introduction about the problem context.

Cocoon Forms provides a binding framework for both loading object properties into form widgets and saving form values into object properties.
This is done through the association of every form widget you want to bind, with a JXPath expression leading to a particular object property.
This is an XML snippet showing a binding example:

<fb:value id="name" path="name"/>
<fb:value id="street" path="address/street"/>

We associate the value of the "name" widget with the "name" property of some object passed by Cocoon control flow, and the "street" widget value with the "street" property contained by the object "address" property.
For bigger clarity, this is a code snippet for the object used in our binding example:

public class Person {
private String name;
...
private Address address;
...
}

And this is its Address property:

public class Address {
private String street;
...
}

The address property is a sort of "complex", or "composite", property.

The problem arises when you want to save form values into a Person object just created, which has a null address property: this will throw a JXPathException because the JXPath context used by Cocoon doesn't know how to create the address property.
So, the following binding:

<fb:value id="street" path="address/street"/>

Will not work.
And, like it, the binding of every complex property with a default null value.

Solutions?

A first one could be to set the address property to a new Address into the Person constructor or in Cocoon control flow, but this is very poor, because requires you to change the business code, or hack the control flow.

A better solution is to use JXPath factories and Cocoon custom binding.
Let me explain my idea.

First of all, create a JXPath factory for making Address objects; this is very simple:

public class AddressFactory extends AbstractFactory {

public boolean createObject(JXPathContext context, Pointer pointer, Object parent,
String name, int index) {

pointer.setValue(new Address());

return true;
}
}

The factory must be set in the JXPath context object, which will use the createObject() method for creating null properties, like "address" in our example (for additional details see the JXPath User Guide and its javadoc).

The question is: how to do that in Cocoon?
The answer is, you can guess it, in custom binding.

First, configure it:

<fb:custom id="street" path="." builderclass="com.example.JXPathConfiguratorFactory" factorymethod="makeConfigurator">
<fb:config relative="address/street" factory="com.example.AddressFactory"/>
</fb:custom>

JXPathConfiguratorFactory is the factory which will make JXPathConfigurator objects through its method "makeConfigurator".
It must be configured, through the "fb:config" element, with two attributes:

1. The JXPath expression relative to the "path" attribute. In our example this is called "relative".
2. The fully qualified class name of the JXPath factory (previously shown) to use, here called "factory".
   

Important: why do we need two different "path" and "relative" attributes?
The reason is that if you set the JXPath expression in the "path" attribute of the "fb:custom" element, Cocoon will try to create the path BEFORE calling the custom binding, causing the well known JXPathException.
So, we must set the "path" attribute to the current context path (which should be existent), and the "relative" path to the desired JXPath expression.

Finally, write the JXPathConfiguratorFactory, as you usually do, and the JXPathConfigurator:

public class JXPathConfigurator extends AbstractCustomBinding {

private Element config;

...

protected void doSave(Widget widget, JXPathContext context) throws Exception {

JXPathContext configContext = JXPathContext.newContext(config);
String relative = (String) configContext.getValue("@relative");
String factory = (String) configContext.getValue("@factory");

context.setFactory((org.apache.commons.jxpath.AbstractFactory) Class.forName(factory).newInstance());

context.createPathAndSetValue(relative,widget.getValue());
}
}

It will simply set the factory into the JXPathContext object, create the null property and set the widget value!

I think that this solution has mainly three advantages:

1. Non-invasiveness : it doesn't require you to change business code or control flow, but only your binding configuration file.
2. Reusable : AddressFactory can be used whenever you need a property of type "Address", and the JXPathConfigurator can be used with every JXPath factory.
3. Simple.
   

I'd like to know your opinion and ideas.

And, as usual ... have a good coding!

Me and AJAX

AJAX, Asynchronous Javascript And XML, is one of those acronyms you have surely read of in some web sites like TheServerSide or XML.com.
It is one of those technologies which rises a great hype, with everyone talking and talking about it.
However, I must admit, I've never read much about it, being too much absorbed by other technologies and ideas, and being a strong supporter of server-side code against client-side javascript.
So, as soon as I've seen its capabilities, I've suddenly got surprised.

How have I encountered it?

A few days ago, as usual, I was working with Cocoon Forms when, testing a form made by my colleague Ugo Cei, I noticed its great responsiveness in combo box dynamic loading and data validation. So, I started browsing the code and while talking with Ugo I've discovered that the high responsiveness was due to AJAX automatic support in Cocoon Forms.
This got my interest, in particular when I discovered that many services like Google Suggest are driven by AJAX.

"Amazing!" I said. "This is great!"

However, after a few hours, my anti-javascript nature began to threat me and my new friend, AJAX... I started to doubt about its support and behavior in different browsers like IE or Mozilla, and so about its real usefulness in production environments.

This led me to further documenting, reading a bunch of good articles which let me understand how AJAX really works: and well, I must say, my anti-javascript nature, this time, was wrong.

So, how does it work?

I'll do a very short description, because you can find a longer (and better) one in the good articles cited at the end of this post.

All the magic lies into a particular javascript object: XMLHttpRequest.
This object lets you, from javascript code, sending an asynchronous request to the server the containing page come from, and receiving an XML document which will be processed by a callback javascript function when the asynchronous request gets completed.
Asynchronous means that the client doesn't wait for the server response, and the web page remains responsive. Moreover, the server doesn't send the whole page, but only an XML document containing the information requested by the client, which will be processed by the callback function, updating data without page reloading.
Here is a step-by-step summary:

1. The web page editor associates a javascript function to an event of an HTML control, say a combo box which, once selected, must fill a text field.
2. This function, called when the user selects some item into the combo box, creates the XMLHttpRequest object which makes an asynchronous request to the server, sending the value of the selected item and then suddenly returning.
3. Meanwhile, the server-side code makes some business logic and sends back the data, formatted in an XML document.
4. When this asynchronous request/response completes, the callback function takes the XML data from the XMLHttpRequest object and processes it, through the javascript DOM binding, updating the text field.
5. All updates gets suddenly displayed.
   

What about my previous doubts?

The XMLHttpRequest object, invented by Microsoft (I've always said that Microsoft guys are able to do something good, in particular when working in rooms with windows closed, in order to keep away from noises and bugs), is still not standard, but implemented by all major browsers, from IE to Mozilla. So, interoperability should not be a problem, and if you want to be safe, you can implement a sort of fallback behavior, like Cocoon does.
Moreover, all the business logic lies server-side (as it MUST be): client side javascript simply makes view processing.

And the advantages?

You can answer by yourself.
Thanks to AJAX, you gain a more responsive interface, which can make the web a sort of new experience, with new
applications like Google Suggest.

Now the links moment:

http://www.adaptivepath.com/publications/essays/archives/000385print.php
https://bpcatalog.dev.java.net/nonav/ajax/index.html
http://www.xml.com/pub/a/2005/02/09/xml-http-request.html

And, if Google has AJAX, why should we not?

Try clicking the "In-line view syndication titles ..." link on the bottom of the sidebar...

Montag WS-I Basic Profile Compliance

This is the first great goal : Montag web services are officially compliant to the WS-I Basic Profile 1.1 recommendations.

It took me an hard work to code and test services WSDLs and all the related stuff in order to achieve this ... but it was very worthwhile and now I feel happy for this result.

Moreover, for this piece of good work I must thank Alex Saloustros for his precious .Net testing, and David Law for his testings about WS-I Basic Profile Compliance.

Congratulations, boys!

Talking about Montag

Montag is my main effort into the Open Source Community.

It is a SOAP Web Services system for interacting with Native XML Databases, but here I don't want to talk about what it is, and what is not ... for this, you can take a look at its web site.
I'd rather want to take a look at its future.

Montag 0.8 will have, first of all, a consistent core code refactoring and rewriting, in order to support new features and better accommodate future changes.
The new features released for the next version will be:

• New services and full document/literal style for all services, based on WS-I Basic Profile.
• New authorization system based on per-service permissions, different from the Unix-like permission system implemented by many Native XML Databases.
• New authentication system using WS-Security UsernameTokenProfile.
• Support for specific non-XML:DB Native XML Databases, like Berkeley DB XML.

All these changes and features are already in development or will start soon to be, but will obviously require a considerable amount of time to be completely developed.
So, prior to the 0.8 final version, a certain number of binary development snapshots will be released, in order to give "fresh meat" to Montag users and to test new features.
They will not be documented, except for some news announcement, but will be supported in the mailing list.

Stay tuned.
Montag's story continues.

It is sunday, it is late evening and tomorrow a new week begins.

On Monday 11 July I've joined Pro-Netics, in Rome, where I will work with great technologies and great minds.



It promises to be a very interesting job and a very exciting experience.
I hope to talk more about it later.

But now ... Shakespeare's Hamlet waits for me.

Good night.

(nice dreams)

Hello all.

It took me a long time to start a blog, but now ... here I am.

What about this blog?

I'll talk mainly about Computer Science, which is my work and my main interest, but also about music and literature, which are my passion, and about every other thing will make sense for me.
Hoping I will find the time!

The play begins.

Welcome.