Is it getting better? Or do I feel the same?

Well, it doesn’t feel the same, that’s for sure, but better? Maybe, a bit.
I certainly know that much more about html, css and javascript, I can tweak spans and trick divs blindfolded by now, but there are still pains and frustration all over the place.
The good:
On a good day, the save/refresh is a candy, debugging the server and client together is nice, I adore IntelliJ (though I used it for flex also so…), seems like component lifecycle is much simpler, I experimented a bit with unit testing and it is really straight forward (unlike FlexUnit).
The bad:
I can spend a whole day on layout, another on style, a few very long minutes waiting for the “amazing” save/refresh which sometimes takes longer than an already long flex compile/run.
What else, let me see, well, cross browser is a real pain, I had a blast trying to get an advanced multi file upload component to look like I wanted it, my glorified button still has some issues (which I will update when I get everything solved), and, well, enough crying for now.
The ugly:
well, so far it's the result...
That’s what I can squeeze right now, not much I know.

Sliding doors button

And now for something completely different, well not really, just a more technical post...
I wanted to share a small widget I created after my long battle with the rounded corner button.
I did not invent anything here, just borrowed some techniques from here and there to propose a small improvement to the sliding doors technique.
You can find many explanations on the sliding doors, I personally liked this post.
The sliding doors technique requires that you add a span element “inside” your button and put the button’s text in it, this way you can use 2 different images as backgrounds to the button and the span (a left and right parts of a button image) that slide one over the other.
What was missing now was a nice wrap so I don’t need to put my text on a span element in an html.
While looking for a solution I stumbled upon this great post on button with image, the button there has exactly what I need, it puts it’s text on an inner span element.
So I used it to create my “EasySkinnableButton”, here is what I did:
public class SkinnableButton extends Button{
    private String text;
    private Element span;
    public SkinnableButton() {
        span = DOM.createElement("span");
        DOM.insertChild(getElement(), span, 0);
    }
    @Override
    public void setText(String text){
        this.text = text;
        span.setInnerText(text);
    }
    @Override
    public String getText() {
        return this.text;
    }
}

The css part:
.gwt-Button span {
    background: transparent url(images/slidingdoors_button_left.png) no-repeat top left;
    display: block;
    line-height: 22px;
    padding: 1px 0 3px 12px;
    color: #fff;
    border-style: none;
}
.gwt-Button {
    background: transparent url(images/slidingdoors_button_right.png) no-repeat top right;
    display: block;
    float: right;
    height: 24px;
    margin-right: 15px;
    padding: 0px 10px;
    text-decoration: none;
    font-family: Arial, Helvetica, sans-serif;
    font-size: 12px;
    font-weight: bold;
    border-style: none;
}
.gwt-Button:hover span {
    background-position: 0 -24px;
}
.gwt-Button:hover {
    background-position: right -24px;
}
.gwt-Button:focus span {
    background-position: 0 -48px;
}
.gwt-Button:focus {
    background-position: right -48px;
}
.gwt-Button:active span {
    background-position: 0 -72px;
}
.gwt-Button:active {
    background-position: right -72px;
}
.gwt-Button:disabled span {
    background-position: 0 -96px;
}
.gwt-Button:disabled {
    background-position: right -96px;
}

when used in a ui binder xml it looks like this:
<button:EasySkinnableButton text=”Tada!”/>

Instead of:
<button:Button><span>Tada !</span></button:Button>

You can also use it programmatically by just calling “button.setTex()”
Here are the images:

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