News from September, 2008

General idea

Since MVC is probably the most most widely used architectural pattern for designing classical web applications it is also appealing choice for GWT. However optimal implementation of this pattern differs quite significantly from traditional web MVC and is much closer to MVC for desktop clients. One of these differences is that the Model in MVC should be allowed to communicate with underlying (business) layer. This is opposed to classical web application where such responsibility is typically given to a Controller. I believe that this applies to RIAs based on other technologies as well unless they have built-in support for some other design.

I think that primary reason for this difference is that in classical web applications you have very little state in client while typical GWT application stores most of interaction state in client. In order to keep system responsive we need to be able to send only specific changes of Model's state from client to server as a response to user actions.

Example

We have an activities management applications (like AMS or Google Calendar) where user can see all activities of current week. Lets compare implementation of use case where user wants to move one activity to the next day.

If we try to apply typical web MVC to GWT application we will have following implementation:

1) browser sends new coordinates of dragged activity to CalendarController
2) CalendarController tells CalendarModel the new column of moved activity
3) CalendarModel calculated new start and end dates for moved activity
4) CalendarModel notifies CalendarController about changes in its state
5) CalendarController sends changed activity to CalendarRemoteFacade on server
6) CalendarController tells CalendarView to redraw changed activity on screen

There can be variations to above sequence but what remains is that Controller is responsible for two things: interpreting user events and synchronizing Model state with server. In case of complex UI it makes no sense to send the whole state of Model to server upon every small change. Therefor Model needs to expose its internal structure and update strategy to the Controller.

Much better solution is to let the Model send its state updates to server:

1) browser sends new coordinates of dragged activity to CalendarController
2) CalendarController tells CalendarModel the new column of moved activity
3) CalendarModel calculated new start and end dates for moved activity
4) CalendarModel sends changed activity to CalendarRemoteFacade on server
5) CalendarModel notifies CalendarController about changes in its state
6) CalendarController tells CalendarView to redraw changed activity on screen

Note that outside of CalendarModel no one is aware that there even is a server. If we want to start using local data store like GoogleGears or change update strategy we just need to modify the Model.

Summary

Although we are used to thinking of Model as simple JabaBean with nothing but bunch of getters and setters the Model in rich client application is something quite different. In fact there is nothing in original MVC pattern that would disallow Model to communicate with some lower layer to persist its state. In paper "Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller" Steve Burbeck says:

Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

My related article on GWT: Presentation and domain model mapping in GWT applications

According to new maintenance policy after every major release (3.0, 3.1, 4.0 etc) bugfix releases for it will be freely available for 3 months. After this time bugfixes will be available in source repository but binary releases will be available only for subscribed users. Also bugfixes to any previous major release will only be available to SpringSource Enterprise customers.

What this means
If you are developing something and can afford to upgrade always to the latest then you probably won't loose much.
If you cannot spend time on testing upgrades then you either have to pay or fix bugs yourself.
If you are developing or maintaining legacy system and have enough money then SpringSource will probably be able to offer better service to you.

Quote from Mark Brewer (employee of SpringSource) on September 19, 2008 in response to Message#268877 at TheServerSide.com:

Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimal point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases. However, the code for fixes will be in the public open source tree.

As Gabriel points out, Enterprise customers will have the added benefit of 3 years of support for any major version that they are running.

Open questions:
Question 1: is it possible that someone can just start taking source from public repository, build jars and makes them available for everyone?
Question 2: how much will Spring Enterprise subscription cost?

Problem

You want to create association based on some advanced condition not just primary and foreign keys.

For example each Asset can have one or more AssetOwners but only one of them is the primary owner.

Solution

<class name="AssetOwner" table="asset_owner">
  <id name="id" column="owner_id">
  ...
</class>

<class name="Asset" table="asset">
  <id name="id" column="asset_id">
  ...
  <join table="asset_owner" inverse="true">
    <subselect>
      SELECT o.owner_id AS primary_owner, o.asset_id
        FROM asset_owner o
        WHERE o.asset_id = asset_id
        AND o.is_primary = true
    </subselect>
    <key column="asset_id"/>
    <many-to-one name="primaryOwner" column="primary_owner" class="AssetOwner"/>
  </join>
</class>

Select contains two columns:

• asset_id which is used to filter out only these AssetOwners who own given Asset
• primary_owner which is used to map only the AssetOwner who is the primary owner

Second important thing is that you must use inverse=true to make sure that Hibernate will not try to persist primaryOwner field when Asset is saved.

As said in article below if you have fixed price project then it may be beneficial not to have very detailed requirements spec referenced in contract

http://feeds.dzone.com/~r/zones/agile/~3/401890175/fixed-price-contracts-agile-pr