Shortlink

Interesting read about Spring Framework 4.0

Groovy/Grails has really spoiled developers like us. Working in Java with core Spring libraries seems to be a bitter pill these days. Though we can configure Groovy classes as beans in Spring it only looks like a plugin in the entire application built using Java.

Thanks to SpringSource, the plans for Spring Framework 4.0 has some good news for developers. To quote one of their recent blog posts,

Configuring and implementing Spring-style applications using Groovy 2:
Groovy-based bean definitions; Groovy as the language of choice for an entire app

An interesting news for Java developers, is the support for Java 8 features like lambda expressions(.NET developers, are you listening???) in Spring 4.0.

You can read the complete post from http://blog.springsource.org/2013/01/16/next-stop-spring-framework-4-0/

Shortlink

Web SQL Proxy in Sencha Touch 2.1

In the previous post, we discussed about Sencha Touch 2.1 including support for Web SQL. Web SQL is a data storage mechanism that enables storing data in SQL databases. The webkit browsers use SQLite database for this purpose. In this article we’ll see how we can use Sencha Touch 2.1 for working with Web SQL.

Sencha Touch 2.1 introduces a proxy class Ext.data.proxy.Sql. We can create a store or model with the proxy type as ‘sql’ and invoke the CRUD methods. At the time of writing this post, Sencha throws too many errors while playing with the Sql Proxy. We may have to wait for it to evolve.

Let’s create a model ‘Country‘ with name and capital fields. The model will use a proxy of type sql. The code is shown below.

        Ext.define("Country", {
            extend: "Ext.data.Model",
            config: {
                fields: ["name", "capital"],
                proxy: {
                    type : "sql",
                    database : "CountriesDB"
                }
            }
        });

In the code above, the proxy has a property called database that specifies the name of the database to be created. Let’s create a Country object and call the save method as shown below.

 
        Ext.application({
            launch: function () {
                var country = Ext.create("Country", { name: "India", capital: "New Delhi" });
                country.save();
            }
        });

After running the script a database CountriesDB is created with a table ‘Country‘ (same name as the model). A primary key column id is generated with auto incremented values. The screenshot of the database in chrome is shown below.

After running the script a database CountriesDB is created with a table ‘Country’ (same name as the model). A primary key column id is generated with auto incremented values. The screenshot of the database in chrome is shown below.

Sql proxy in Sencha Touch 2.1 is still not fully functional as it throws up errors while trying to load the records or customize the table name. We may have to wait for it to mature before using it in our applications.

Shortlink

Web SQL support in Sencha Touch 2.1

It’s really surprising of Sencha Touch 2.1 to introduce support Web SQL feature. Web SQL enables creating and maintaining databases in the client. We can store hierarchical data in web sql databases. Browsers like Safari and Chrome provide an SQLlite implementation of this feature. The Web SQL specification work has been removed by W3C due to various issues. The industry has moved on to IndexedDB instead.

In this context, the introduction of Web SQL support in the form of an SQL proxy in Sencha Touch 2.1 comes in as a surprise. The feature works perfectly well in all webkit browsers and can be used in real time applications. The API is lot more easier compared to the traditional syntax of working with Web SQL.

In the next article we’ll discuss SQL proxy provided by Sencha Touch 2.1 in detail.

Shortlink

Groovy 2.0 and static type checking

A common sentiment echoed by developers of Groovy is that Groovy being a dynamically-typed language, makes them catch the syntax errors on type-safety only during runtime. The answer to that is Test Driven Development. Unfortunately a majority do not use TDD in their projects. Groovy 2.0 has come to their rescue through static type checking. Though, not a great fan of this feature, it may provide some smiles on the developer’s faces.

We have two classes Person.groovy and PersonUser.groovy as shown below. While writing this code we’ll make a couple of silly typos as shown below.

//Person.groovy
class Person{
 String name
 int age
 def eat(){
  "${nme} is eating" //error
 }
}
//PersonUser.groovy
class PersonUser{
 static void main(args){
  def p1 = new Person(name:"Sam",agee:12)//error
  println p1.eat()
 }
}

Running PersonUser.groovy will report error while creating an instance of Person as “agee” is not available. Even if we fix that the p1.eat() statement will throw an exception as we have misspelt name in eat method.
It’ll be better if the Groovy compiler reports these errors during development than waiting for the runtime to report it.

Groovy 2.0 introduces an annotation @groovy.transform.TypeChecked which can be applied on classes or methods. Rewriting the code to use this annotation will report a compile-time error as shown below.

//Person.groovy
@groovy.transform.TypeChecked
class Person{
 String name
 int age
 def eat(){
 "${nme} is eating" //[Static type checking] - The variable [nme] is undeclared
 }
}
//PersonUser.groovy
class PersonUser{
@groovy.transform.TypeChecked
 static void main(args){
  def p1 = new Person(name:"Sam",agee:12)//[Static type checking] - No such property:agee for  Person 
  println p1.eat()
 }
}

The static type checker of groovy reports an error and you’re happy to fix it now in development phase. The problem is adding the @TypeChecked doesn’t seem to cooperate with the dynamic features of Groovy. For example, the following code will work fine without the type checking.

class PersonUser{
 //Uncomment the line below and you'll notice blood bath
 //@groovy.transform.TypeChecked
 static void main(args){
  Person.metaClass.work = {
    "${delegate.name} is working"
  }
  def p1 = new Person(name:"Sam",age:12) 
  println p1.eat()
  println p1.work()
 }
}

Adding the Type checker ruins the party. The same seems to be the case with closures as well. Uncommenting the TypeChecked annotation in Person class will report errors in the closure doSomething.

//@groovy.transform.TypeChecked
class Person{
	String name
	int age
	def eat(){
		"${name} is eating"
	}
	def doSomething = {i->
		i++
	}
}

The static type checker tries to resolve the dynamic features of Groovy and fails.There’re a number of rules where the static type checking works and doesn’t. We need to be aware of them before you use the type checker.

Shortlink

Yii

A framework that we are using currently for a project is Yii. It expands to Yes It Is :). It’s an MVC-based PHP framework.

Before beginning the project a number of frameworks were taken into consideration. Grails, Node JS etc., and finally it was decided to use to PHP (something that I have ignored for a long time). A number of PHP based frameworks were then considered and finally Yii was nailed.

Yii is free for commercial use as it has been released under BSD license. My first few lessons on Yii reminded me of Grails. The same controllers, models and views. Once the coding started started wondering how I have ignored this for a long time. It’s so nimble without any heavy duty plumbing work. Much lighter and simpler than Grails. Eclipse has a good Yii plugin that’s more than enough to get started with.

Yii controllers can be accessed in REST style, so seems to be a perfect candidate for server side implementation for mobile applications. The models follow the ORM mechanism known as ActiveRecord(similar to Ruby). But the ActiveRecord implementation of Yii is lot more simpler than the Rails and Grails(GORM) counterparts. The best part about creating ActiveRecord classes is you don’t have to declare all the variables that correspond to the columns. It supports relationships, criteria API as well.
The view components are our standard PHP pages where you can use HTML UI components provided by Yii, similar to the custom tag libraries.

Like the standard question we face from Java/.NET developers regarding Rails/Grails, does it support developing enterprise level applications or used only for social media type applications?, I have the same question and still working on it. Another aspect of Yii, that’s still need to be explored is the unit and integration testing capabilities similar to the Grails framework. Yet to use PHPUnit.

But yes, it’s definitely worth looking at Yii for future projects.