I’m studying Flex in these days, and I followed the very same path to handle navigation among views (opposed to pages): viewstack, custom components, events dispatching.

After some years of development for the web, I feel a little lost.. maybe, the AS/MXML should offer some way to describe user navigation concepts (simple jumps, wizard-like, etc.). It seems like Flex does a fine job designing the interaction between the user a single, estabilished view, but force you to code all the navigation logic.

To date remains also hard to find good documentation on this obvious migration issue; that is, web designer to Flex designer. Bottom line: the level of componentization that is obviously required if you were to build a 50 page site will require the web designer to learn a whole lot more actionscript than they knew or would like, with a likely ouotcome of them building it in a way less than idea way given their likley lack of OOP basics.

All that said, having been a Web designer with 12 years of deep experience in HTML/CSS, request/response web apps, I”m pumped on Flex and more eager than ever to get my OOP chops together so I can build complex Flex apps as they should be built.

My recommendation, which it seems is already in the works, is for much more upfront examples and sample code for the most likely migration issues.

cheers, ethan

I think view stack components can defined their own API when loaded that can publish events and frameworks. This can be used to initiate a single from any component like comp1.call(); that will return a map of that component to use… we have many comps in our mail application that does the same trick once loaded…

Ku Sir, I would expect some of your comments on this.

Tx

Let me give more background on where my thoughts come from, including the conceptual starting point of “pages”, which I believe was important to the success of the web.

1) My main worry is that it is too easy for those of us who do programming as a living to forget how important simplicity is for the adoption of a new technology.

Concepts such as objects, events, MVC, etc., are fine when creating big applications or reusable components.

However, when creating a one-off project, people shouldn’t need to learn how to define, dispatch, and catch events just to get their applications built.

Let me take an example from Mac programming in the 80s. In many ways, HyperCard was a direct predecessor to the web. It used a page-based metaphor, along with a simplified scripting language. On the other end of the spectrum was MacApp, which was a framework for serious programmers.

HyperCard and MacApp are for two totally different classes of users and applications. You wouldn’t want to design a full blown desktop app in HyperCard, and you wouldn’t want to introduce MacApp to someone who wasn’t already very comfortable with OO concepts.

The beauty of the web is that it encompasses both types of users and applications. Very simple things can be built simply. Meanwhile, technologies like the J2EE stack exist to service larger, more complex sites.

Both sides of this spectrum are important. My concern is that Flex does not do enough to service the “keep it simple” end of the spectrum.

2) When I talk about things being a “big glob of goo” as far as the outside world is concerned, my concern is not with load time or componentization.

The issue is that the rest of the web is built with the assumption that applications are broken up into states, and that these states can be captured in the URL (see http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). Unlike the true REST advocates, I understand that session state and other factors make it impractical to always store state in the URL, but in 80% of the cases, the URL does just fine.

Web applications are not the same as desktop applications. Decomposing a web app into individual states that are captured through the URL has lots of indirect benefits (scalability, deep linking, indexability, etc.) that we should not take lightly.

Thanks for taking the time to write. I’ll keep posting more thoughts as I learn more about Flex.

Using deferred instantiation, the components in your viewstack can be really instantiated when they are required.

Decomposition of your application is very important. It is completely bad form to make anything but a trivial example in one big hunk of swf bytecode.

The samples application has a pretty neat way of doing something similar.

all loose mxml files that are pulled together at the last moment.

As far as your thoughts about encapsulation and chain of command, you might want to check out the lightweight microarchitecture for Flex called Cairngorm. it uses the frontcontroller/command patterns to solve changes between the main application states. Although you define this as “overkill”, it really is not for maintainable pages.

If you ask: why do I need patterns/architecture for something as trivial as a “go to page”: that is because of your conceptual starting point: a series of pages instead of a combination of screen elements that can interact.

The right way to solve the encapsulation is having your button broadcast a specific event, and the application listening for this specific event. That way the application doesn’t have to know about the existence of the button, the event can also originate from a menu, a keyboard shortcut etc. etc. Take a look at event dispatching and publish subscribe posibilities in Flex.

cheers,

ilya

For me, the REST issue is not solely about encoding the state of the app in the URL. It’s a philosophy of how to put web apps together: the site is broken up into pieces, and the state information is passed back and forth.

Whether you like it or not, REST *is* important because the rest of the web (ha ha) depends on it. URLs are central to how search engines, bookmarks, the refresh button, deep linking, etc., etc. work.

As to Paul’s point.. passing in a ViewStack seems like it would be a good medium-weight solution. But I still miss the simplicity of . I mean.. I can get my head around components because I’ve done lots of Windows and Mac programming. But there is a simplicity to the Web that I hope we aren’t overlooking….

We can do REST in Flex with the help of history management, but it’s not clean, and I don’t like to think of Flex applications like that.

http://www.klynch.com/archives/000076.html
http://www.livejournal.com/~mannu/263246.html

There’s the page-based paradigm of web applications, and there’s the window-based paradigm of desktop applications. I believe RIAs are somewhere in the middle, and as a result people coming from both camps are likely to be confused while doing their first apps (you’re not alone). It can take a little getting used to, and that worries me sometimes. We need more “getting started” type training material, but also some examples of how to migrate traditional web applications to the Flex way.

>How does the application know that the welcome panel has a button named “newAccountButton”?

It shouldn’t. WelcomePanel should just broadcast its own event — let’s call it “newAccount” — and handleEvent should care about that. The “newAccount” event would be a part of the public API for the WelcomePanel component. How the “newAccount” event got triggered — whether it was because of a mouse click or a network event or whatever — is what’s encapsulated.

and then the welcomePanel can act on the ViewStack locally. This way the component doesn’t have to know anything about the structure of the application and the application doesn’t have to that there is a Button inside the component which triggers the jump to the next state. Does this meet your encapsulation goals without being overkill?