Separation of Screen logic and the Screens

On our radar
I need a good way to create Screen logic but not have it directly tied to the screen. It would be best if the screen logic could be stored in another eSpace. This way, I could have multiple eSpaces leveraging the same screen logic and adding their own logic on top and only apply bug fixes to one eSpace. Also, this is important if I want the same logic behind a mobile application and the desktop version.
Created on 29 Jul 2011
Comments (4)
I'm not sure what you mean with "screen logic" here. Actual screen behaviour is tied to the widgets on the screen, so you cannot import it from another eSpace. If you need entire screen blocks, you could use webblocks (especially if, in the future, they can be used with input as well). All other logic can be in actions, which you already can import from another eSpace.
Kilian -

I meant exactly what I wrote, and you understood it exactly the way I meant it.

I need the LOGIC separate from the SCREEN, including "Preparation". I don't want Web Blocks, because they do not achieve that goal, they still tie UI to logic.

I work on a lot of applications which are fundamentally identical, except for some details of a few entities, and which entities are displayed on the screen. Right now, I need to clone a base eSpace, then modify the entities and screens as needed. If a bug is found, the fix needs to be manually applied to all of these eSpaces (or merged). If I could put the core logic into a shared eSpace, but the actual entity and screen definitions into another, errors in the logic could be fixed in one spot and immediately applied, especially if I could overlay the eSpace's Actions on top of the "library" version (like adding additional Preparation work).

I understand the issue, but it's got a pretty big impact on the whole truechange I think.

Still, not sure why you even have 2(+) pages. with webblock hiding/showing you can easily choose which page you need and with styling you can add extra functionality.
Joost -

With the Web Block approach, I'd have to duplicate large amounts of functionality in a number of scenarios. And sometimes, the styling changes we want to make are massive (like when we make a page designed for printing).

Finally, the Web Block approach still doesn't address the scenario where we have multiple applications that we want to share the same logic, but have different attributes for fields that are not being directly used in the logic.

Basically, I'm asking for something like MVC.