Sunday, December 14, 2008

Sanjiv Comment on ppl argue with Pure Gwt and Javascript Wrapper ( SmartGWT )

Compile output size and runtime performance are two separate issues. A
third party widget written in GWT Java, regardless of how small it compiles down
to, doesn't magically make it run fast. Nor does it make it magically render
perfectly on all browsers. As an example a TableGrid written in GWT Java could
still perform really poorly, and not display consistently on all browsers.
There are obviously several aspects to GWT that helps avoid leaks and such
but this does not mean that any third party code written in GWT is
100% leak free. The GWT 1.6 event API is really neat and SmartGWT users
it. Well written code is what will perform well and display consistently
across various browser.
On the issue of performance, there are numerous posts
made by paying GXT users that the performance of GWT-Ext is still better than
GXT. You can search their forums. This is not to suggest that performance
improvements cannot be made in SmartGWT. If you can give specifics, it would
certainly help in resolving them. But without specifics like whether it was the
initial load time, performance of specific widgets etc it will be difficult to
act on. Feel free to post on the SmartGWT forums or create an issue on the
smartgwt google code project.
On the issue of compile output size : The
SmartClient library is extremely stable and developed over the past 8 years.
If you peruse their forums, you will find that pretty much all questions
are met with an answer explaining how the user can accomplish what they're
trying to do. Their library is virtually bug free. I realize this is a strong
statement, but its true. Only some 4-5 issues were patched
post-release. Compare this to the bugs forum of any of
your favorite libraries. SmartGWT will inherit these attributes
once its past the few initial minor releases and issues are flushed out during
this period. Due to the high level of stability of SmartClient, it can be
viewed as the kernel of your web app which should be configured to be
gzipped with an "Expires Never" header for a given version. This means that the
browser will cache the "kernel" (SmartClient JS files) and the only code that
gets downloaded is your application code, and not any code related to the widget
/ framework. Future releases of SmartGWT will provide a GWT linker that only
pulls in the required files so this should cut down the total size of the
application.
The SmartGWT showcase has some 250 samples which is 6 times more
than the GXT showcase so its not quite apples to apples when it comes to initial
load time.
Finally please read my blog entry http://www.jroller.com/sjivan/entry/smartgwt_1_0_released if
you haven't already done so. I go over the SmartGWT fundamentals, the concept of
a DataSource and how it will lead to a cleaner architecture and can cut
application code significantly. I mention how a master detail page can be
written in as little as 10 lines using a reusable DataSource definition that
describes an entity / model class. Plus the reduced number of lines of code on
the server as well.This is the first release of SmartGWT and while it is quite
stable and has been tested and used by early adopters for the past four weeks,
users can expect any rough edges / bugs / performance issues / better skins etc
to be ironed out over the course of the next few minor releases.As mentioned
earlier, if users have found a library that meets their needs, thats great and
there's no need to look further. And for the others, feel free to evaluate
SmartGWT to see if it helps meet your requirements. If you feel that there are
things that can be improved please post on the SmartGWT forum or create an issue
on the google code project page.

Friday, December 12, 2008

Gwt UI Component with Fluent Interface Pattern

Fluent Interface pattern Fluent Interface is come from Martin Fowler. These types of design pattern are often utilized to create configurations for your objects but can progress into an internal Domain Specific Language or DSL.

I will use GWT as a sample to point out the issue of Swing like development with HTML\tag style for UI programming. In GWT/Swing like coding style, have you found out that the number of line of code is much more than tag style. Look at the following explanation.

Gwt Button with out Fluent Design
Button disabledButton = new Button();
disabledButton.ensureDebugId("cwBasicButton-disabled");
disabledButton.setEnabled(false);
disabledButton.setWidth("11");
disabledButton.setHeight("11");
disabledButton.setTitle("Disable Button");
disabledButton.setFocus(true);
//Come on!!! still set again.. :( ..How many line already!!! that is just one UI component...
.....
...
..
.

HTML / Tag style
All the properties can be in one line and optional.
< button title="Disable Button" width="11" focus=" true" height=" 11" enabled=" false" ensuredebugid="cwBasicButton-disabled" />

Gwt Button with Fluent Design
Button disabledButton = new Button()
.ensureDebugId("cwBasicButton-disabled").setEnabled(false).setWidth("11").setHeight("11").setTitle("Disable Button").setFocus(true) ;

Fluent like coding style is something like tag/annotation style of code. It is good to configure an object.

Constructor way of coding
No wait a minute, We can use Constructor to passin the properties so it can be in one line of code.
Maybe you can create constructor for the Button object with all the properties but how many combination of properties you can create. Bad design because it is not easy to read.
Button disabledButton = new Button("cwBasicButton-disabled", true, true); //what is the true true for? Which one is enabled? Which one is focus?

public Button ( String ensureDebugId, boolean enabled, boolean focus){...}
public Button ( String ensureDebugId, boolean enabled, String title ){...}
public Button ( String ensureDebugId, boolean enabled, boolean focus){...}
// you can create somemore for other properties...if you are hardworking.

Make Button with Fluent Interfaces Design Pattern
So in order for GWT/Swing like coding style to solve all this issues and to minimise the number of line of code and readability. Fluent interfaces pattern has to be implemented.
All the UI component should be coded in the following way. All setters have to return this own for the subsequent statement to call again.

Button SetTitle(String title){
this.title= title;
return this;
}
Button SetEnabled(boolean enabled){
this.enabled= enabled;
return this;
}
...
..// for all the setter of the properties

Button with Java5 Annotation
With the Java5 Annotation support, you can easily configure an object in Attribute Oriented Programming way. But do you think gwt support annotation in runtime mode? The answer is no. But we can use it via gwt generator wich mean in the compile time.
@ButtonProperties( ensureDebugId="cwBasicButton-disabled", enabled= false, width=11, height=11, title="Disable Button", focus=true )
Button button = new Button();

Fluent Interfaces Pattern in SQL
let see how it can be in Sql.
Query = q = new Query()
.select("name","age").from("Student").where("age").between(12,20).where("gender").is("M")
This can be easily refactor and avoid typo error. Sound good right!!!


Finally, i hope our programming trend is going to attribute oriented programming and fluent Interfaces Pattern. THE WORLD IS JUST CONFIGURE

GWT 1.6 going to release soon

Happy to see that GWT 1.6 going to release soon. Estimated on Q1 2009. Compiler performance improvements is a high demand feature in gwt group from all GWT developer. Hopefully it can reduce the compilation time to 50% and more. Other than that will be Developer Guided Code splitting, to avoid download all javascript at the first load.


Release 1.6

  • New compiled file deployment structure
    • Easily compile into a war file structure, making it easy to deploy your compiled GWT application into standard servlet containers
  • Migration from Tomcat to Jetty hosted mode server
    • A more pluggable architecture for the hosted mode server will enable developers to use servlet containers other than Tomcat with the Hosted Mode browser
  • Uniform event handlers
    • Event handlers will be implemented in a uniform fashion across all widgets, with listeners deprecated
  • DatePicker, LazyPanel migrated in from incubator
    • New widgets from the incubator
  • String performance improvements
    • StringBuilder uses deferred binding to optimize string appends per-browser
  • Compiler performance improvements
    • 1.6 will introduce parallel permutation compilations and other performance tweaks for faster compiles


Post 1.6

  • Developer Guided Code splitting
    • Developer guided code splitting is a mechanism that allows developers to specify asynchronous split points in their code where the code base can be split and downloaded in different chunks. This is currently an R&D project but looks promising.
  • Analysis of compiled code, aka Story of your compile (SOYC)
    • Aims to give developers concrete information about their compiled JavaScript, such as which Java classes are generating the most JavaScript code.
  • In-browser hosted mode, aka Out-of-process Hosted Mode (OOPHM)
    • In-browser hosted mode will allow GWT developers to debug their apps within a browser rather than GWT's hosted mode browser
  • UI Binder
    • The UI Binder will allow the creation of UI elements in a declarative fashion. Watch for UI Binder to land in the GWT incubator soon.
  • Client Bundle
    • Client Bundle implements the power of deferred binding used in Image Bundle in a generic fashion so that it can be used on many resources. These include TextResource, ImageResource, and CSSResource
  • RPC performance improvements
    • Ongoing work to improve the performance of RPC