Lorand, I believe there is a big role of UI controls and common classes of pages in your framework.
It is hard to perform efficient coding without commonly accepted base functionality - which is a foundation of lexicon, requirements and semantics.
This lexicon defines what things ARE and what things DO - primitive or composite. Noteworthy, elaborating those concepts - we will find sustainable communicational (integrational) schemes between components - which are more that the sum of parts. You will undertstand me if you created and supporting UI framework more than 2 years.
This is a kind of evolution of knowledge - when long time is needed to realize fundamental blocks from many prospectives, and then - begin realizing their efficient communication, tuned explicitly, or implicitly on top of characteristics of component.
I don't believe in efficient conceptions. Any MVC is nothing without a stable set of components and working samples. Absolutelly agree with Matt about the boundary, untill there are still many efficient architectures which break that rule, but provide more security and less boring code. Good architecture helps to achieve compromis, but unfortunatelly - conceptions are very general and they lead to tonns of unstable code if practiced literally.
Dmytro, I fully accept your concerns. I have worked a lot with GUI in C/MFC, Java/Swing, J2EE with JSP and some web frameworks, ObjectiveC/Cocoa, C# whatever (that was short). I did not like those frameworks (yet, Objective C is "almost there") because they all focused on implementing the requirements in a system - and again asked the wrong question. The question I offer here is: What is GUI? Why we create it?
The answer is: we want to let the user interact with data. Not "creating and handling selection change event" or "disabling a control". Talk with data. In this way, the answers are more simple:
- we have a finite GUI control set in our environment (like Java Swing, GWT or ExtJS). Create wrappers that listen to their OWN changes; handle their OWN parameters (can load from a configuration and apply them); and also their OWN states (visibility, enabled, style);
- we need a data layer ABOVE the actual data (forget about using POJO here). I use plain old HashMaps hidden behind an API. It is 1: fast enough on these machines, and 2: the core implementation can be improved without touching the using codes if (1) is not true anymore;
- open this data layer to the GUI framework and the business logic you need in your current task
- we need an identification and listener mechanism that transfer control and let them talk to each other
- and not to forget: a shared status reporting mechanism that allow each component to "complain", which the GUI can display and the Process can use (abort on error)
This is really complex, I admit. However
- should be done once and in the long run, worth the time (you only need to implement the actual business logic in all the next systems)
- has nothing to do with the actual business needs - or in other words, these are the business needs to build a GUI framework :-) (this is THE recipe to create stable code: focus on exactly one thing in a component, so the more you know, the less you change)
- does nothing else than you would do in any system GUI (only the weird stuff is concentrated into one component instead of typing them in all the time), so this far is as efficient as direct coding
- yes, I use maps instead of objects, which is of course, slow. What I get? No getter/setter functions with listener management, no long, framework-bound "Control" codes. In fact, zero direct GUI code, because the required business logic interact with data, and not GUI controls.
That ten years old framework had an XML based configuration, an editor to build the GUI, renderers to create interactive Java Swing for fat AND Javasrcipt/HTML based web clients, and PDF output - not to mention that it run without GUI when we needed mass update from text files. We used other configuration to connect business logic on the data the GUI worked with - it got control on change, and the GUI got control to update its content. However, actual GUI coders did not know anything about it, because they had to
- create the GUI configuration, put it into the system and it appeared (of course it was modular, so could use pre-created fragments);
- select the required standard logic components (dates, users, filing information, etc) and connected to the data items, so they have shared, tested, stable Ergonomy/Consistency elements, still without coding;
- create the custom Ergonomy/Consistency logic. Still without knowing anything about the actual GUI framework, because they interact with data, not the GUI (or other internal, Process components)
... and they did not care about storing the data, make their stuff appear in common lists, be printed to pdf or mailed to the mentioned people because that was in the Process logic layer. The greatest problem I heard of was that working with it is boring. Considering the dark magic behind, I take it as a compliment :-)
