This Place Just Oozes Passion
I spent a lot of time here eight years ago, commuting between San Mateo and Calgary on a weekly basis for over a year. It's nice to come back to the seems-like-recession-proof Bay Area for technical inspiration. It, like no other place I know of, absolutely oozes passion for technology - primarily software technology. There was a breakfast/registration this morning and it seemed like everyone was giddily running around like a bunch of crazed schoolgirls waiting in line for the premier of Twilight. Honestly? I'd like to take some of that passion home with me and spread it around.
Ya-Who?
As I walk down the street, within one hour I inadvertently find the homes of many of the technology companies we've come to love and hate. Cisco, Citrix, AMD, Intel, WebEx, Oracle, Sun... err... IBM, Yahoo, etc. Seems like they're all here... all within a few square kilometers. Speaking of Yahoo, their campus still has an incredibly large footprint. It seems to go on and on. Blocks and blocks of buildings, floral gardens, manicured courtyards, etc. I bet they hire three gardeners for every programmer. Every second car in the parking lot is BMW - although maybe they're 1999 vintage, purchased when the now 30-somethings where hired as up-and-coming 20-somethings looking to take over the world. Who knows. What the hell does Yahoo do anyway? I thought they disappeared when Google came along. I stopped using them - didn't you? Guess not.
Mac's Everywhere
Another thing I'm noticing is the disproportionate number of MacBook versus Windowz machines. I'd say it's at least 2:1 in favour of the Mac's. The table I'm sitting at now is 4:1. There's the odd Linux guy back there, but from what I can tell you're only using a PC because you didn't have to pay for it. What's interesting to me is that a lot of the committers are using OSX too. Maybe now that 3.5 runs native on OSX, everyone feels like the the Mac is now ready for Eclipse. Not sure. As a more-than-casual Mac user myself, I can tell you that Eclipse runs great on Windows and okay on OSX. Saying that, I haven't been using 3.5 for very long and the SWT folks spent basically all of 3.5 porting the Carbon code to Cocoa. Maybe I'm in for a pleasant surprise.
Morning Session - Binding, Commands & Common Navigator Framework
Binding - The Better of Two Evils
Anything to get rid of that boilerplate we have to write just to get our models in sync with our UI. It's such a trivial problem that just begs for a declarative solution. I must say, I think the Eclipse guys are going down the right path. I find the same two problems, over and over, with most declarative solutions in this UI binding space. Firstly, most solutions take away control when it comes to the timing/event that drives the binding. You lose to fine grained control you need in rich-client UI's. Secondly, bindings only work with a specific handful of widgets. I'm happy to say that there's a decent answer to both of these problems.
For problem #1, the framework allows us to specify the event.
DataBindingContext dbc = new DataBindingContext();
ISWTObservableValue ui = SWTObservables.observeText(myTextWidget, SWT.Modify);
IObservableValue model = BeansObservables.observeDetailValue(myModel, "body", String.class);
dbc.bindValue(ui, model);
Most of you are going to look at this code and cringe. At least I hope you will. I'll give you the benefit of the doubt and assume you're going to say that this is a terrible way to express a binding because reflecting into a Bean to get its property value exposes you to a bunch of runtime errors where an alternative solution would allow compile-time error checking. Well you're partly right. The problem is not the framework, it's Java. I don't see my way clear to an alternative solution. If you do, please share. Now if this were Scala, where I'm allowed to pass methods as parameters for example, I see a completely different approach that is both declarative and type safe. But that's another topic for another day. That day is probably right around the corner because its been bugging me for a while.
For problem #2, just roll your own. The binding is pure API, supported by a bunch of helpers all over the place. There are built-in solutions for the most common elements: fields (text, date, boolean, etc), lists, tables and trees. They even provide a solution to the common Master-Details problem. But, if your use case calls for a new UI component that isn't covered, just write your own. I haven't tried this yet, but look forward to do so.
Update Strategies & Validation - Arghhhh... Java - You Suck!!!
Good idea, bad implementation. To be fair to the guys, they're handcuffed here. Friggin' Eclipse is still hanging on to Java 1.4. I mean really... we're on 6. Does anyone really still use 1.4? I think this topic deserves its own post, because if I see another snippet of code that looks like this I'm going to apply for one of those "Yahoo Gardener" gigs.
new UpdateValueStrategy().setConverter(new IConverter(){
public Object getToType() {
return Date.class;
}
public Object getFromType() {
return String.class;
}
public Object convert(Object from) {
// convert your String to a Date
}
};
Are you kidding me? That would never pass a code review anywhere I've worked. Let me see, can we make this a little better?
new UpdateValueStrategy().setConverter(new IConverter<String, Date>(){
public Date convert(String from) throws UnconvertableFormatException {
// convert your String to a Date
// because it's any string, I'll make you handle the exception
}
};
Please tell me that its clear to the decisions makers over at Eclipse Headquarters that the lack of generics support in the Eclipse framework really creates a major problem when it relates to technology adoption. Anytime I'm writing code that integrates my models with an Eclipse UI, I feel like I might as well be writing all this stuff in Ruby. I might as well turn off incremental compilation because I'm passing a bunch of Object references around. Once the Eclipse frameworks get a hold of me, all my types have been lost. To get them back, I'm casting all over the friggin' place. Discussions with a couple of the committers indicates that they're also frustrated with these handcuffs. Rumors seem to point to e4, but I'm going to hunt for a definitive answer while I'm here.
Commands - It's All About Scale and Extension
I'll just say a couple of things about the declarative Command framework. First of all, for those of you looking for an 'undo' solution, this is not it. Not that it can't be used for that use case, but that's not what it was developed for. Secondly, there seems to be a bit of a bad smell around 'best practices'. The guys running the session didn't get into the value proposition. They started with "here's how you do this" and "here's how you do that". Nobody wanted to talk about "why do I want to do this?". When I asked the question, the answer was weak to say the least. Don't get me wrong, I absolutely see the value proposition. It's about extension and scale. If I want my business application to also play the role of platform, i.e. host for extension, then I want the extender to have options too. Perfectly valid. But if I'm just building a small application on top of the RCP stack then I don't see why I'd want to declare my commands outside. There's definitely an overhead I have to pay in terms of development and tool support.
Assuming I want this capability, the Command declaration gives my application a way to show my commands in a menu without loading the class, which is all possible because of Equinox. At-the-end-of-the-day, the Command framework is simply further UI decoupling of the legacy ActionSet strategy. Again a step in the right direction.
Common Navigator Framework (CNF) - Platform Navigation
CNF is about providing a solution for a common integration/extension use case. "Let me put my stuff in your tree view". One plugin can show Projects, another plugin can show Tasks. CNF allows you to do this without binding the two plugins. It does so in such a way that the user doesn't have to use two separate navigation views. Nice.
Afternoon Session - Advanced RCP
First things first - it's not that advanced. We were presented with "best practices in RCP" using a sample MP3 application. All-in-all, I liked the session because it brought everything together. The funny thing about it is that while it brought together many of the frameworks, it did uncover many inconsistencies. For example:
Best Practice #1 - Use Adapter Factories
"Use adapter factories (IAdapterFactory) to adapt your models to the binding context needed at the time". For example, if you want your model to show up in a tree, do it this way.
treeViewer = new TreeViewer(parent, SWT.BORDER| SWT.MULTI| SWT.V_SCROLL);
IAdapterFactory adapterFactory = new AdapterFactory();
Platform.getAdapterManager().registerAdapters(adapterFactory, Mp3File.class);
treeViewer.setLabelProvider(new WorkbenchLabelProvider());
treeViewer.setContentProvider(new BaseWorkbenchContentProvider());
Simple. Register your adapter and the BaseWorkbenchContentProvider will find the adaption in the factory. We don't need to get into the adapter code here - it's not the point. The point is that I don't have to use any content provider other than the one provided by the workbench. That begs the question, "why are you making me specify it then?", but I'm not going to chase that down right now. Anyway, not a big deal. It works. I get it. Great. Sure. Whatever. Now for Best Practice #2.
Best Practice #2 - Use Virtual Tables
"When you have large datasets, only load what you need". Ya, no kidding. Sounds like a plan.
TableViewertableViewer = new TableViewer(parent, SWT.VIRTUAL|SWT.BORDER|SWT.V_SCROLL);
// skipping the noise
tableViewer.setItemCount(100000);
tableViewer.setContentProvider(new LazyContentProvider());
tableViewer.setLabelProvider(new TableLabelProvider());
tableViewer.setUseHashlookup(true);
tableViewer.setInput(null);
What? LazyContentProvider? Didn't you tell me less than 10 minutes ago that I'm to adapt via an IAdapterFactory and use the BaseWorkbenchContentProvider?. Make up your mind! Turns out that #1 and #2 are not only incompatible, but they're mutually exclusive. Awesome. NOT!!!
Enough About Day #1
In the end, I don't want to be hard on the guys. They're pumping out some good stuff and the Eclipse ecosystem is such a huge machine that it's almost impossible to keep it all together. It's evolving in the right direction. For the rants I do have I should probably put all this blogging energy into contributing to Eclipse.
Looking forward to the e4 sessions tomorrow afternoon.
No comments:
Post a Comment