The Artima Developer Community
Sponsored Link

Articles Forum
Rich-Client Misconceptions

5 replies on 1 page. Most recent reply: May 5, 2008 11:00 PM by Frank Sommers

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Rich-Client Misconceptions Posted: May 5, 2008 11:00 PM
Reply to this message Reply
Advertisement
Rich clients are more than just about user interfaces, argues Adobe's James Ward in this JavaOne 2008 interview with Artima:

http://www.artima.com/lejava/articles/javaone_2008_james_ward.html

What do you think of the current state of developers working with designers when building Web applications? Do you agree that rich-client technologies, such as Flex, make that collaboration easier?


johny boyd

Posts: 28
Nickname: johnyboyd
Registered: Apr, 2007

Re: JavaOne 2008, Day 1: Rich-Client Misconceptions Posted: May 6, 2008 9:46 AM
Reply to this message Reply
I think rich-clients - using Flex or whatever, have their place in a certain class of applications. Usually for 'enterprise' type UIs which perhaps need a richer set of UI controls than the typical web app.

I don't think rich clients are the best option for your 'consumer' or 'social-network' type webapps. For e.g., can you do mashups with a Flash/Flex generated site? Or display on a mobile device?

btw, 1000 engineers working for 5 years to develop an Ajax app - surely that's a typo in the article?!

-jb

Jiri Goddard

Posts: 54
Nickname: goddard
Registered: May, 2007

Re: JavaOne 2008, Day 1: Rich-Client Misconceptions Posted: May 6, 2008 11:18 AM
Reply to this message Reply
it's always good to have designers and programmers in co-op (games are good example). some tools, like adobe's tools (notice that i left out the technology part) should make it easier, otherwise i'd not call them tools :)
what can adobe, or any other company offer to make the co-op better while working on rich client (not on ria)? isn't all about people communication? you can have hundreds of tools and technologies, but if people won't speak to each other, the tools (and techs) will not do the work alone.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: JavaOne 2008, Day 1: Rich-Client Misconceptions Posted: May 7, 2008 9:36 AM
Reply to this message Reply
Well, once again, folks who either weren't there or haven't read the history.

What Rich Client is/should be about is re-creating the world of VT-220s connected to *nix databases, circa 1990; albeit now with pretty pixels instead of characters.

It is specifically not about client-server; which was created to solve a very different problem: how to distribute processing (and NOT data) to this (then) new fangled thing called an engineering workstation. CAD/CAM systems (on *nix, of course) were an early (perhaps first) use-case. Previously, CAD/CAM was done on dumb graphics terminals connected to 370s.

C/S offered the opportunity to off-load *non transactional* processing of sparse data sets from the mainframe to engineering workstation (client). This allowed the mainframe to be a mini-computer, and thus made DEC, etc. very profitable. These systems were semantically unlike the Web of today, or any sensible Rich Client of tomorrow.

The notion that graphic rendering is "client" of client-server melieu is factually wrong. It just happens that client workstations in CAD/CAM systems in client-server did a lot of rendering; but this is not the same thing.

The current Web is exactly the same system model as the mainframe/3270 of the 1970s (with a longer, slower wire): a disconnected block mode client with downloaded edit programs for the user screen. Just pretty pixels today.

The ability to have a *connected* client (pixelated terminal now) interacting in real-time with the datastore over a much longer wire is what's being attempted. For transactional processing, it's the connectedness (and not the ability to have state) that matters. As my Pappy used to say (with regard to having transactional state on the client): just because you can do something doesn't mean you should.

Anyone who asserts that storing transactional state on clients should read up on distributed database. It will save you a lot of pain.

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: JavaOne 2008, Day 1: Rich-Client Misconceptions Posted: May 11, 2008 9:42 AM
Reply to this message Reply
I steered the designer that does UI concepts for my Flex dev teams to a Visio template for mocking Flex UI.

He ended up telling me that he preferred to just use Flex Builder to mock Flex UI as it was more productive for him and gave him a more functional result to mess around with.

When I brought in professional Flex training for my dev staff last year, I also let this designer and a UI usability person take this training too. They didn't always follow all aspects of the training as when it dived into deeper programming concepts. None-the-less, it did pay off for them (and the company).

Perhaps Thermo will ease all this for designers, but the approach we're using now is not so bad.

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: JavaOne 2008, Day 1: Rich-Client Misconceptions Posted: May 11, 2008 9:54 AM
Reply to this message Reply
Is Flex RIA only suitable for business application interfaces, or apps like Buzzword (a highly functional word processor)?

Often it's believed that a web RIA approach is perhaps not so optimal for content heavy web sites (the blogging and social web sites, etc).

However, there are two aspects of Flex that could be leveraged to integrate content and yield a more dynamic UI.

First is that a Flex app can be built like a portal. A Flex form can dynamically load other Flex forms in a nestable like manner. The sub forms loaded can be determined by logic that executes at runtime. The loadable modules can be built as totally standalone components. They can bind into the hosting portal environment using Flex properties, events, and declarative data binding features. So the coupling layer can be well abstracted so as to not be overly brittle.

Second, one can incorporate a popular iFrame Flex control into a Flex form, which, of course, the iFrame can be used to load HTML/JavaScript content. So highly dynamic web content can be integrated into the UI of a Flex RIA application.

Thirdly, Adobe AIR has WebKit HTML engine built-in, so an AIR app can also ready make use of HTML content in a integrated fashion.

Fourth, there are already mechanisms that can be hosted in Apache httpd and IIS that will compile Flex forms from source code on the fly. So some aspects of even the Flex RIA could be generated dynamically at runtime. Currently these mechanisms are intended for development phase purposes. The compilation is not considered fast enough for production sites. However, in time this will likely improve.

In the meantime, my preferred approach is Flex form modularization and Flex control iFrame for embedding HTML content.

Flat View: This topic has 5 replies on 1 page
Topic: Visualizing Cluster-Based Applications Previous Topic   Next Topic Topic: The Law of The Big Two

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use