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/
midrange.com
