We were developing some custom widgets which are working OK for SWT. Now I would like to have it working on RAP as well, while sharing (single-source) the implementation with SWT.
What we've planned for this would be to have a ui.common project which would then be extended by the ui.swt and ui.rap projects with the specifics parts.
Now that we really are to start developing with RAP we've actually realized that a custom field / composite must extend either the SwtScoutFieldComposite or the RwtScoutFieldComposite, which doesn't allow for clean single-sourcing (via extension of a common class).
1. Is there any recommendation to achieve RWT/SWT single sourcing within Scout context?
2. Is there any reason for Scout not to have it ready for (beside historical reasons of RAP having been developed afterwards SWT, so maybe was chosen to duplicate the code?)?
3. Maybe we are newbies on this and in fact single-sourcing between RWT/SWT is kind of a "urban myth" that actually doesn't work well on real world applications?
We could think on some abstraction model that would instantiate a common class at the SWT/RWT fields, which would receive the SWT/RWT object to access the scout model object and environment. Then the SWT/RWT object would have to add the correct listeners to the common created widgets to implement the differences between the technologies. This would made us also wrap the Environment classes so that it could be a transparent API (map to the SWT/RWT Environment API)
This doesn't seem good coding for us (as I would say it isn't clean to read the explanation) and a simpler approach would be more interesting.
I can fully understand your needs.
At the time we started developing an RWT implementation of Scout we started with one single code base for RWT and SWT. Pretty soon we had several hard coded switches to fix some issues for the one or the other rendering engine. So in RWT it is rather a bad idea to use GC drawings or the file chooser does behave fully different in Web applications also table, tree, smartfield, timechooser, datechooser and more. Furthermore several layout issues can easily be solved with CSS vs a hard finger work in rich clients.
So we decided to fully split the SWT and RWT rendering engines and keep the flexibility of the two worlds.
To answer your questions:
1) No, Scout does not provide a solution for single sourcing RWT and SWT renderers.
2) See explanation above.
3) To keep the flexibility also in future I would advice to split the RWT and SWT rendering engine strictly.