Why is state management a problem? Could you give a sample scenario? Have all screens be tied to an application session instead of managing page per page. A giv

Why is state management a problem? Could you give a sample scenario? Have all screens be tied to an application session instead of managing page per page. A given screen stays put the entire session (although may be hidden or removed as needed). Its state would be hierarchically addressable & examinable, such as requesting "scopeA:screenB.panelC.widgetD.value". (Scoping clause optional.) I have some further suggestions for state and scope management that would take up too much space here. The Oracle Forms client seemed to somehow pull it off. (It used a proprietary markup, not XML.) There are deficiencies with the Oracle Forms model, but it proved a browser-like GUI client approach can work. Companies loved Oracle Forms before Java ruined it. They weren't pretty, but cheap and practical to create and maintain. The Oracle Forms devs were 3x more productive than our MVC team and it took about 1/5 the code to do the same thing. Productivity died in CRUDville; we de-evolved. (Same for desktop VB & Delphi like tools, although they required per-PC reinstalls for app upgrades, unlike Oracle Forms.)