The Button

One thing I noticed very quickly is that every time I Google some GWT issue I get the same 3-4 web sites, GWT official site and 2-3 blogs, that’s it. If you think about it, it’s pretty neat because I already know all of them top to bottom and I can stop wasting time on the net.

My last task was styling a button, I started by doing some reading on the various ways to do styling, pretty quickly I figured it is not going to be as smooth as it is in Flex.

I quickly tried the different methods (2 days and 5 hours) and I focused on the “sliding doors” technique (2 images used on the button and on the “span” object inside the button to achieve a button with image as skin that can expand to the width of its text).

Some copy paste from the only example I could find, a quick build, e voila: I get a button that looks like a picture of Dali. 2-3 more tweaks to the css, few hours to understand I need to remove the “text” from the button and move it to the “span” and it started to look like a button.

I spent the next few hours with the excellent FireBug plugin to get rid of a stubborn pixel glitch, and at last, while I'm exhausted but with a sense of achievement my button was ready.

Hmm, not really, I made the mistake of trying it on other browsers, I now got 2 distorted versions of my infamous button.

Cross browsers, yeah right.

Frustration

The last week was a real knock on the head, waking me from the comfort of doing what I am used to do for about 3 years now – writing UI in Flex.

Why frustration? Well, I guess there are a few reasons for that, first, I am not a complete noob in the dev world, but since day one I was dealing almost entirely with Flex, yes, I have some knowledge in Java, html, some server mumbo jumbo etc. but I really am a Flex guy.

I think that beside the obvious difficulties in learning a new technology, I suffer from more profound and specific issues.

In the past years I was part of a team that set the standards of how we write client side code in my group, we decided on the architecture, gathered some helpful tools and passed the knowledge to the other developers.

Our main design pattern was the “presentation model” paradigm, in a nutshell, the pattern dictates separating  the view from the business logic, putting all the logic in a presentation model (PM) class that controls the behavior and data of the view, our interpretation to this pattern was that we have the view in MXML files, and the PM is an ActionScript class that implements an interface, the view is injected with its PM by his parent view, we also used Spring ActionScript across our application for IoC purposes.

The first thing we encountered when looking into GWT was that it is focused around the MVP pattern, although the PM and MVP pattern share much of the characteristics, they are different.

In GWT, most examples and frameworks use a reversed relationship from what we did in Flex – the presentation class in GWT “knows” its view through an interface, the view is the one that implements the interface.

In first look, it seems like a nuance, what’s the big deal? Well, maybe it’s not a big deal, but it gave me a big headache J

This small difference means a completely different lifecycle of the application, it also means there is a dependency tree in the presentation layer since a presenter is responsible of creating the presenters of its view’s children (a complicated sentence, sry).

I want at least some of you to read my next posts, so I will not continue discussing the differences between the two approaches, let me just say, it took some time and effort to change the way I think about design.

I still can’t say I am completely comfortable with this new approach, but I do my best. 

Intro

This blog is created so I can share my journey of converting from a Flex developer/enthusiast to a GWT developer (enthusiast? – who knows).

I bet many UI developers will take this journey, for many different reasons.

Although this is not a technical blog, I hope you can find some interest in it.

To be continued…

ziso