JaroslavTulach at 20:22, 7 January 2010 - 2010-01-07 20:22:35

←Older revision Revision as of 20:22, 7 January 2010
Line 7: Line 7:
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?
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 ''role'' interface in the context 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 ''role'' interfaces and their proper implementation.

JaroslavTulach at 20:20, 7 January 2010 - 2010-01-07 20:20:57

←Older revision Revision as of 20:20, 7 January 2010
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 context 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?
+
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.

JaroslavTulach: New page: There is another reason why differentiate between MVC and DCI. Recently we had a polemic discussing whether NetBeans uses Swing correctly or not... - 2009-10-31 08:48:30

New page: There is another reason why differentiate between MVC and DCI. Recently we had a polemic discussing whether NetBeans uses Swing correctly or not...

New page

There is another reason why differentiate between [[MVC]] and [[DCI]]. Recently we had [[RationalismVsEmpiricism|a polemic]] discussing whether [[NetBeans]] uses [[Swing]] correctly or not. After receiving [[Talk:RationalismVsEmpiricism|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, [[modularity|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 [[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 context 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.