DCIAndLeakyAbstractions
From APIDesign
| Line 5: | Line 5: | ||
As a result we are not testing a single [[MVC]] triad, but a very big number of unknown triad's combinations. Each of the data (originally a model) is different, yet it gets morphed into the same context when necessary. However, same does not mean absolutely equal! Remember that [[leaky abstractions|abstractions leak]]! The context required by an interaction is an abstraction and all the morphed data shall be uniquely morphed to it. They can try, but still there will be differences. Some mappings may be faster than other and that is why sometimes it may be appropriate to query the data while painting and sometimes not. | As a result we are not testing a single [[MVC]] triad, but a very big number of unknown triad's combinations. Each of the data (originally a model) is different, yet it gets morphed into the same context when necessary. However, same does not mean absolutely equal! Remember that [[leaky abstractions|abstractions leak]]! The context required by an interaction is an abstraction and all the morphed data shall be uniquely morphed to it. They can try, but still there will be differences. Some mappings may be faster than other and that is why sometimes it may be appropriate to query the data while painting and sometimes not. | ||
| - | For example recently we noticed an action in [[NetBeans]] that needed to find out whether currently selected project supports [[Java]] 5 or some later version. Given the advices of [[DCI]] it searched for a | + | For example recently we noticed an action in [[NetBeans]] that needed to find out whether currently selected project supports [[Java]] 5 or some later version. Given the advices of [[DCI]] it searched its context for a role called '''SourceLevel''' with a method returning the [[Java]] version of the selected project. Obviously it did this during painting to find out whether it shall be enabled or not. For most of the project types (usually [[Ant]] based) this worked fine. However for [[Maven]] projects this could took ages. Who's to blame? |
Either the ''data'' are provided too slowly. Then the [[Maven]] would need to be sped up. However sometimes it just takes time to get an information. Then the ''interaction'' needs to be improved to deal with ''data not ready yet'' and the ''context'' interface needs to be enhanced to allow expressing such temporary data unavailability. Various situations may require different solutions, but in general it is not possible to say ''AWT thread shall be used only for painting''. It can be used only for that in [[MVC]], but in the [[Module system|modular world]] this also requires well designed ''context'' interfaces and their proper implementation. | Either the ''data'' are provided too slowly. Then the [[Maven]] would need to be sped up. However sometimes it just takes time to get an information. Then the ''interaction'' needs to be improved to deal with ''data not ready yet'' and the ''context'' interface needs to be enhanced to allow expressing such temporary data unavailability. Various situations may require different solutions, but in general it is not possible to say ''AWT thread shall be used only for painting''. It can be used only for that in [[MVC]], but in the [[Module system|modular world]] this also requires well designed ''context'' interfaces and their proper implementation. | ||
Revision as of 20:20, 7 January 2010
There is another reason why differentiate between MVC and DCI. Recently we had a polemic discussing whether NetBeans uses Swing correctly or not. After receiving some comments I felt totally unsuitable to use Swing or even program. As this is not true, I started to seek for reasons why people say things like: Why was the event dispatch thread used for non-painting computation in the first place?
Swing is following the MVC design path. View displays its associated model. This means that during painting (on the event dispatch thread) one needs to query the model. The silent assumption here is that the model is going to answer quickly, not require really long computation. This is easy to achieve when one instantiates the whole MVC triad. However, modular applications are more like DCI - someone provides the data, someone else provides the interactions (for example actions, or various presenters) and someone completely else binds these elements together.
As a result we are not testing a single MVC triad, but a very big number of unknown triad's combinations. Each of the data (originally a model) is different, yet it gets morphed into the same context when necessary. However, same does not mean absolutely equal! Remember that abstractions leak! The context required by an interaction is an abstraction and all the morphed data shall be uniquely morphed to it. They can try, but still there will be differences. Some mappings may be faster than other and that is why sometimes it may be appropriate to query the data while painting and sometimes not.
For example recently we noticed an action in NetBeans that needed to find out whether currently selected project supports Java 5 or some later version. Given the advices of DCI it searched its context for a role called SourceLevel with a method returning the Java version of the selected project. Obviously it did this during painting to find out whether it shall be enabled or not. For most of the project types (usually Ant based) this worked fine. However for Maven projects this could took ages. Who's to blame?
Either the data are provided too slowly. Then the Maven would need to be sped up. However sometimes it just takes time to get an information. Then the interaction needs to be improved to deal with data not ready yet and the context interface needs to be enhanced to allow expressing such temporary data unavailability. Various situations may require different solutions, but in general it is not possible to say AWT thread shall be used only for painting. It can be used only for that in MVC, but in the modular world this also requires well designed context interfaces and their proper implementation.
Follow
