« July 2005 | Main | October 2005 »
August 30, 2005
New Flex/Zorn talks at MAX
Hi folks. If you're planning on attending MAX and have an interest in Zorn, you should check out some of the new sessions that have been added. Some of the smartest people I work with will be presenting.
NJ Jaramillo is a combination UI designer / programming god, who will be presenting about Flex 2.0 UI and layout, and James Polanco, one of the leaders on the Zorn QA team, will be giving a general overview of Zorn.
Ely Greenfield and David George, two of the architects of the Flex framework, will be giving talks, as well as Gary Grossman, who has been involved with almost every aspect of Flash over the years, and is (a) the fastest typist I've seen, (b) the fiercest coder I've seen, and (c) one of the nicest guys I've met.
In addition, we will have a three hour overview session on Zorn which should prove interesting.
Mark and I will be around as well. Hope to meet you at MAX!
P.S. For those who are interested in Dreamweaver (something I worked on for a long time prior to this gig), the new version is fantastic and you should definitely check out some of the talks.
Posted by sho at 1:39 PM
August 19, 2005
Web 2.0, RIAs, AJAX, and the semantic web (lowercase s)
Enough buzzwords for ya?
A long time ago, I remember having a conversation with Tantek Celic about how RSS/tags/etc have started to form a loose taxonomy of information. Tantek calls it the semantic web with a lowercase s. The reason this has so much momentum is because it's a grassroots effort. Instead of creating a taxonomy the way a librarian would (top down), each person decides how to tag information, and tags tend to coalesce. He later joined Technorati, which just shows how strongly he holds these convictions.
Nowadays, there's a lot of talk about Web 2.0, web mashups, AJAX, etc., which in my mind are all facets of the same phenomenon: that information and presentation are being separated in ways that allow for novel forms of reuse.
To some extent, this is closely related to service-oriented architectures, except that saying SOA makes it sound like you wear button down shirts, work at a large company with lots of consultants and so forth. Saying "web mashup" sounds like.. well.. the opposite.
Until the recent popularity of AJAX, the architecture of HTML-based Web apps and Flash/Flex based applications was quite different. In old school HTML-based apps, the controller logic and most of the presentation logic resides on the server, and feeds relatively dumb content down to the browser, which means that all the plumbing between the presentation and the back end services was all done behind a curtain.
Now, with AJAX-based apps, the client makes service requests and assembles presentation on the client machine, which is exactly what Flex/Flash-based apps do, and is one of the drivers behind Web remixing, as Jonathan Boutelle pointed out recently.
What would be nice to see at this point is a set of least common denominator interchange formats for common types of data and operations. Will this ever happen? Hard to say. Unlike with tagging, which is driven by the masses, APIs are driven by a few companies. The Flickr API is different from the smugmug API. What would cause that to change?
I think the only way this could change is through grassroots efforts, but I can't quite picture how that would evolve. Perhaps some guerilla projects by people to write adapters between APIs? The FOAF project is one example of a group trying to standardize how information is represented, although I can't tell how much progress they have made.
In any case, at the risk of stating the obvious, all this is great for RIAs. The trend of increasing separation between front end presentation behavior and back end services allows RIAs to get in the mix. Applications like Paul Neave's excellent Flash Earth wouldn't be possible without it.
Posted by sho at 1:31 PM
August 18, 2005
Flex/Flash Architectural Challenge (part 2)
In the previous part of this challenge, I was asking the question of whether model/view separation was enough for most RIAs, or whether MVC was required. As a concrete exercise, I thought it would be good to imagine building a specific small app, so I picked Ta-da List.
I took some time to sketch out what I think a model/view version of this app might look like in Flex pseudocode. How would an MVC version be structured differently?
ListApp.mxml--
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*" initialize="onInitialize()">
<mx:Script source="ListApp.as" />
<mx:HDividedBox width="100%" height="100%">
<mx:Panel title="My Lists" width="200" height="100%">
<mx:List id="listOfListsView" width="100%" height="100%" dataProvider="{listOfLists}" cellrenderer="ListOfListsRenderer" change="onSelectedListChanged()" />
<mx:ControlBar>
<mx:Button label="new list" click="onNewList()" />
</mx:ControlBar>
</mx:Panel>
<mx:Panel title="{selectedList.title}" width="100%" height="100%">
<TodoListView id="todoListView" width="100%" height="100%" dataProvider="{selectedList}" />
<mx:ControlBar>
<mx:Button label="add item" click="onAddItem()" />
<mx:Button label="edit" click="onEdit()" />
<mx:Button label="share" click="onShare()" />
</mx:ControlBar>
</mx:Panel>
</mx:HDividedBox>
</mx:Application>
ListApp.as--
// included from ListApp.mxml
var session : ListAppSession; // Magic session state variable which I will imagine is already populated.
var user : ListAppUser;
var listOfLists : ListOfLists;
var selectedList : TodoList;
function onInitialize()
{
// Ask the static factory methods of ListAppUser and ListOfLists classes to fetch
// data from the server and create instances of my client side representations.
user = ListAppUser.getInstance(session.userId);
listOfLists = ListOfLists.getInstance(user);
// Once these get filled in, data binding will take care of view updates.
}
function onNewList()
{
// When a new list is requested, pop up a dialog, and call the model to ask
// it to add a new list.
var dialog : NewListDialog = PopUpManager.createPopUp(this, NewListDialog);
var handler = function() {
listOfLists.newList(dialog.fields.title, dialog.fields.description)
};
dialog.addEventListener("ok", handler);
}
function onSelectedListChanged()
{
// Query the listOfLists object for the contents of the selected list.
// Data binding ensures that the view is updated.
selectedList = listOfLists.getItemAt( listOfListsView.selectedIndex );
}
function onAddItem()
{
// Adding an item works differently than creating a new list, because the
// TodoListView handles it. It already knows which list to add to, because
// its data provider is data bound to selectedList.
todoListView.onAddItem();
}
function onEdit()
{
// Similiarly, going into the "edit state" is handled by todoListView.
todoListView.editable = true;
}
function onShare()
{
// Sending email is handled by the todoList object, which ultimately sends a web service request.
selectedList.sendAsEmail();
}
Posted by sho at 8:03 PM
Flex/Flash Architectural Challenge
This discussion about MVC in RIAs has made it clear that different people can mean slightly different things when they talk about MVC. Once we got down to specific examples, the differences seemed to disappear.
So let's get even more specific. Suppose you were building a Flash/Flex version of Ta-da list. What would the appropriate client side architecture be? What classes would you have, with what responsibilities? If you haven't seen the app before, check it out. It's a small, convenient app made by the folks who put together Ruby on Rails.
My personal belief is that for an application of this scale, you could build it cleanly without a controller, and that the code may be simpler as a result, but I could be totally wrong. In the meantime, prove me wrong! (or better yet, prove me right!) Tell me how you would build it.
I'll offer a Macromedia T-shirt (hopefully a Flex/Zorn shirt, although we don't have any yet...) to the person who contributes the best ideas to this thread.
Full disclosure: If you feel particularly territorial about your ideas or code samples, please be warned that any insights you give may make their way into Macromedia samples / documenation / etc. In other words, please don't share anything you don't want us to share with others.
Posted by sho at 12:55 PM
August 17, 2005
On state management
As part of the conversation about MVC, Grant Skinner brought up state management. I believe having centralized state management is critical, although I don't consider that the same thing as a controller.
Flash based apps tend to have recognizable "locations". These may include things like a login screen or an index page. Controls may also have states, such as an "up" state and a "down" state. Using a centralized dispatch mechanism for states is a good idea. I don't think of that as the same thing as a controller, but people seem to mean different things by the word controller...
Posted by sho at 2:31 PM
August 16, 2005
MVC considered harmful
Recently, I've been thinking about the appropriate way to wire up Flex applications, and I've come to the conclusion that... drumroll please... MVC is probably not needed for most RIAs. Or more specifically, application of the FrontController pattern is probably overkill for the vast majority of Flex apps. (I know that Steve and Ali are going to disagree with me violently...)
Let me caveat all this by confessing my general tendencies as a programmer and engineering manager, which can be summarized by one word: laziness. And as a lazy programmer, I'd never really gotten into MVC in desktop GUI programming. For me, separation between view and model was the important thing. Separating out the controller from the view seemed to be more trouble than it was worth.
MVC actually makes sense for the HTML-based world, because there is a physical separation between the view, which lives on the client machine and the model, which lives on the server machine. Logic to respond to user events usually needs to be handled on the server. Does it make sense for the model to take care of these events? Of course not. Ergo, you need to separate out the controller logic from the model logic.
There are nasty things about this approach as well. You often see architectures in which a single controller handles all of the "actions" for the entire application. I see this as a necessary evil, not a "good thing". The world of the giant switch statement is exactly what we wanted to avoid with OO programming, right?
With Flex, you have a powerful engine on the client that can perform complex logic and directly access Web services. Because of this, the forces that propelled everyone to adopt MVC need to be reexamined.
For some applications, it may make sense to separate out controllers for the application. And for certain components, it will probably make sense to use the MVC pattern for that component just like in the Smalltalk days. But for the majority of apps, I think that separating the view from the model is the big win, and in most cases, the "model" part of your application consists of services that live on another machine, so that separation is something that you have no choice about.
Ok. Flame away!
P.S. Heidi, our engineering manager, came back from sabbatical last week, so my days are becoming a little less hectic, hence this post. *whew*!
Posted by sho at 7:22 PM