Re: Flex & RPG

although being "out there" is a specialty of yours ;-)

I knew I wasn't completely off my rocker! :-)

In the end I think the key is to NOT use something as verbose as XML -
especially when both ends of the pipe are owned by the same party. I guess
I am getting learn all of these things the hard way, but at least I know
from where I speak :-)

The RPG Open Access coming in V7.1 should hopefully peel back some layers
for people (including myself) to have a lightbulb over the head moment and
realize the approach of 5250 data streams and subsequently spark ideas of
how to morph it into the "next big thing".

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/


On Thu, Mar 11, 2010 at 9:46 AM, Pete Helgren <Pete@xxxxxxxxxx> wrote:

Aaron,

Just as an FYI, Mike Meservy, who was a member of a company I was
involved with several years ago, had a company called Vultus that had a
product called WebFaces that used XML and a browser based plugin that
did just what you described. I am not familiar with the details, but
they eventually had to create a caching mechanism because of the number
of screens/images that could possibly be rendered at the client. They
had a designer that used components that the browser plugin could
recognize and render. The commands on what to render and what actions
they generated and the data were sent using XML. There is an article
without much detail here:

http://findarticles.com/p/articles/mi_m0EIN/is_2002_Oct_2/ai_92349825/

Mike sold the technology to SCO and they shelved it.

So what you propose is probably a little further to the right of left
field than you might think, although being "out there" is a specialty of
yours ;-)

Pete


Aaron Bartell wrote:

Were you seriously considering that?

Absolutely! I have built the equivalent in Java where I send down a
configured screen (using XML in this case) and the Java parses the XML

and

renders the UI components on the screen. Each UI component included an
"onAction" attribute that when invoked will send the form back up to the
server along with the action take and the server program will respond

back

to the client with whatever screen it wants to display next (I programmed
the client to do stacks of screens so the server program could simply say
"remove the current screen from the stack and go up one level").

The only thing lacking was a screen designer which is instrumental for
quick/easy development. That is why I am so intrigued by what ExtJS is
doing with their tool. They essentially have a similar concept where
everything is more based on configuration AND they are coming out with a
screen design tool.

The issue I have with Flex and similar technologies is deployment of new

and

changed screens. As soon as the client has to care about whether or not

it

has the latest version of a screen you create a maintenance/failure point
that a shop needs to be concerned about. That's why 5250 was so nice
because it always downloaded the "screen" components and didn't try to,

or

need to, cache anything - and the emulator knew how to render that data
stream to the user and process user events back up to the server.

Am I still out in left field? :-)

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.