M
marian.edu
Guest
Wow, back to the religious war, as a post from Rom today explained it might be better not to stop talking about it (religion) but to embrace that and talk about it in a civil manner 
Stefan is clearly in a disadvantage here so although I disagree with him when he say frameworks are bad I have to play the ‘devil advocate’. Sometimes it’s kinda hard to differentiate between a ‘components suite’ and a ‘all-in’ framework… the later can simply be just a collection of components that can be interchanged so how that could be any worst than using components from different vendors? Other times the frameworks just grow to be way to complicated (spring anyone) and the separation between components tends to fade away everything becoming too tightly coupled, guess this is what Stefan is referring to as an ‘all-in’ framework. My humble opinion is that frameworks are not bad but are no silver bullet either so use them when needed and prove useful for what you need to do, don’t just adopt a framework because you have to have one. As a bonus for Stefan on the process progress issue, you really don’t need multi-threading nor sockets to do that… Eclipse’s ‘progress monitor’ approach can work very well in a single-threaded 4GL application. Build the long running operations to accept a ‘progress monitor’ as an optional parameter, if that is provided the long running operation can report back progress (by calling a method in the progress monitor instance, an interface is preferable) and very important don’t forget to check if the user want to cancel the operation. You can then call the method with a ’null progress monitor’ if you don’t care about progress or pass in a monitor that can for instance update a slider or progress-bar in UI to inform the user about the current progress. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212
Continue reading...
Stefan is clearly in a disadvantage here so although I disagree with him when he say frameworks are bad I have to play the ‘devil advocate’. Sometimes it’s kinda hard to differentiate between a ‘components suite’ and a ‘all-in’ framework… the later can simply be just a collection of components that can be interchanged so how that could be any worst than using components from different vendors? Other times the frameworks just grow to be way to complicated (spring anyone) and the separation between components tends to fade away everything becoming too tightly coupled, guess this is what Stefan is referring to as an ‘all-in’ framework. My humble opinion is that frameworks are not bad but are no silver bullet either so use them when needed and prove useful for what you need to do, don’t just adopt a framework because you have to have one. As a bonus for Stefan on the process progress issue, you really don’t need multi-threading nor sockets to do that… Eclipse’s ‘progress monitor’ approach can work very well in a single-threaded 4GL application. Build the long running operations to accept a ‘progress monitor’ as an optional parameter, if that is provided the long running operation can report back progress (by calling a method in the progress monitor instance, an interface is preferable) and very important don’t forget to check if the user want to cancel the operation. You can then call the method with a ’null progress monitor’ if you don’t care about progress or pass in a monitor that can for instance update a slider or progress-bar in UI to inform the user about the current progress. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212Continue reading...