Linked by Thom Holwerda on Wed 4th May 2011 20:41 UTC, submitted by lemur2
SuSE, openSUSE The first major effect of Attachmate buying Novell (and thus, SUSE) has come into, uh, effect. Novell, of course, is the birth place of Mono, the open source implementation of Microsoft's .NET framework. Reports indicate Mono developers have been fired as part of the streamlining process, but according to Attachmate's CEO, they weren't fired because of Mono.
Thread beginning with comment 471979
To view parent comment, click here.
To read all comments associated with this story, please click here.
StaubSaugerNZ
Member since:
2007-07-13


I've looked it recently. Didn't realize you could develop UIs outside of code now.

But I stll have other problems with it. It's component set is very primitive for example. Granted, there are third party add-ons to solve that, such as SmartGWT.

The other problem I have with it is that for very large projects, the compile / test cycle becomes somewhat unmanageable.


Once you have your GWT-RPC calls sorted out you generally don't restart anything. Instead you refresh the browser and the what looks to be incrementally-compiled Javascript gets loaded. So generally you just do browser page refreshes to see the latest changes you have made.

From your objections it sounds like you haven't tried GWT yet - it ain't perfect by any means, but it is pretty good and betterer than the 'old' (lol) style way of working with raw Javascript libraries (where you worry about browser differences a lot), and page-oriented systems (soooo inflexible from the user's point of view).

Edited 2011-05-06 04:06 UTC

Reply Parent Score: 2

pantheraleo Member since:
2007-03-07

[q]
I've looked it recently. Didn't realize you could develop UIs outside of code now.

But I stll have other problems with it. It's component set is very primitive for example. Granted, there are third party add-ons to solve that, such as SmartGWT.

The other problem I have with it is that for very large projects, the compile / test cycle becomes somewhat unmanageable.


Once you have your GWT-RPC calls sorted out you generally don't restart anything. Instead you refresh the browser and the what looks to be incrementally-compiled Javascript gets loaded. So generally you just do browser page refreshes to see the latest changes you have made.

From your objections it sounds like you haven't tried GWT yet


I have tried it. And I didn't care for it much. Compile / test cycles were too long on large apps, The Eclipse plugin was unstable and buggy. And when something does go wrong in the generated Javascript, debugging it can be a nightmare from hell sometimes.

I also think GWT exposes too much of my application's business logic to the client.

Edited 2011-05-06 04:18 UTC

Reply Parent Score: 1

StaubSaugerNZ Member since:
2007-07-13

I also think GWT exposes too much of my application's business logic to the client.


Only if you design it badly. The business logic should be on the server, with display logic on the client. Validation happens both on client and server. You can never trust clients!

Reply Parent Score: 3

pantheraleo Member since:
2007-03-07

And no, I don't work with raw javascript libraries that much. My preferred solution right now is JSF2 / Facelets with a decent component library such as PrimeFaces or OpenFaces, combined with Spring for dependency injection, controller, and persistence management.

Reply Parent Score: 2

StaubSaugerNZ Member since:
2007-07-13

And no, I don't work with raw javascript libraries that much. My preferred solution right now is JSF2 / Facelets with a decent component library such as PrimeFaces or OpenFaces, combined with Spring for dependency injection, controller, and persistence management.


Arrgh! JSF(1) was simply awful. I've not tried JSF2 though.

Reply Parent Score: 2