Skip to main content

Adobe Flex 4 brings UI Development to the Next Level

Last Thursday I attended the Chicago Flex User Group meeting and the topic was Adobe Flex 4 and Flash Builder 4. The Flex 4 framework brings the development of user interface to the next level. With Flex 4 the skinning and layout process is now separate from the individual objects and containers like HBox and VBox no longer exist. The container is replaced with layout definitions that is part of the skin class. It is fully integrated with Adobe Catalyst so applications can quickly be developed. I see a big potential for Domino applications running with a Adobe Flex or AIR interface.

As a result of the big announcement that Apple refuses to support Flash on the iPhone, there was definitely an anti-Apple sentiment at the meeting. A couple of Flash developers I know are switching from iPhones to Android because they are that pissed off at Apple. I personally use a Blackberry.

Comments

Palmi said…
Richard , yes new Flex 4 is going to be great am making a lot of wishes these days so here one more. Flex 4 is based on Eclipse so is our great Notes. Would it be great if we could get a Notes plugins on Flex4 . Where we can get Views and data source ,elemetns into flex. just an idea.
Palmi,

How about a AIR based Notes client that is lightweight. I have not had a chance, I am wondering if you can surface the Domino Server-side Javascript into Flex?
Patpicos said…
Hi Richard, there are posts in the yellowverse showing how to trigger server side stuff from the client. its regular JS so I guess Flex would be able to call on it.

However, I dont know if that would apply to validators and stuff.

Check Tommy Valand's blog
Patpicos,

I will look into that. That opens up a number of interesting possibilities.
Ed said…
Codestore.net has extensive examples of Flex/Domino integration. I think that Flex is great, but Adobe isn't going to win a grudge match with Apple. HTML5 is almost certainly going to displace Flex/Flash within a few years, so I'm ending my Flex career before it even started and gearing up for HTML5.
Ed,

The Apple versus Adobe grudge match is really not of any concern for me since I do not develop for the iPhone nor do I see developing for it in the future. It was just an observation. HTML 5 holds a lot of promise, but it has a long way to go. Also there are fundamental reasons why a thicker client is needed. I do not believe that HTML 5 will fulfill it and Flash and Sliverlight will still be around much longer then you think.
Jerome Carter said…
Hi Richard,

Briefly, on getting server side items exposed in the flex client and JavaScript... Flex has an ExternalInterface class which makes access to local JavaScript possible. So any functions you can expose in your client side page which contains your movie can be accessed via this class. Lots of possibilities here. To get at server side items, you need a server side api of some sort. I currently use the mx:httprequest object extensively for all sorts of data needs in the flex movie whenever I need something that doesn't fit the use of JS functions or classes. Adopting a pattern where your server side code is organized and exposed via agents or pages allows clean separation of your "view" and your "controller" so IF you have to switch away from Flex for some reason, you can and not need to get rid of your server side work. The catch is that you'll find yourself doing things in flex with data that make sense for flex sake - things that may not remain true if you used a widget or other UI component.

Jerry Carter
Jerry,

It sounds very similar to what I have been doing with my UX Pages Project. I haven't play enough with XPages yet, but it sounds like that the XPages mx:httprequest object utilizes the xhrGet and xhrPost of dojo to provide a transport mechanism and I should be able to integrate in even the server-side Javascript into my UX Pages Project. I am just in the process of completing the initial integration of Dojo into UX Pages.

I am a big fan of separating the data from the UI so what you are saying is the right approach.

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

The iPhora Journey - Part 5 - Dammit Jim, I'm a LotusScripter not a JavaScripter

As often said by Dr. McCoy in the original Star Trek series, he is a doctor, not a ____________ .  However, just like Dr. McCoy, you may sometimes need to work on things that seem very alien to your experience.  One of those things, might be JSON. LotusScript, which was derived from Visual Basic, was written long before JSON existed, and therefore, LotusScript had no built-in capabilities for handling JSON objects. As we mentioned in Part 4, JSON plays a critical role in iPhora.  All data are stored as JSON, and JSON serves as the primary data and communication format between modules, functions and services.  All core components operate using JSON-based configurations.  Therefore, it was extremely important that we are able to fluidity create, read and process JSON.   Creating a JSON string is relatively easy in any programming language. You can create it even using Commodore 64 Basic, and if built sequentially, one line at a time, it is possible to create JSON representations of ve