<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: e4 and RAP</title>
	<atom:link href="http://eclipsesource.com/blogs/2009/02/20/e4-and-rap/feed/" rel="self" type="application/rss+xml" />
	<link>http://eclipsesource.com/blogs/2009/02/20/e4-and-rap/</link>
	<description>Eclipse Equinox OSGi</description>
	<lastBuildDate>Sun, 18 Jul 2010 08:59:03 +0200</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kevin McGuire</title>
		<link>http://eclipsesource.com/blogs/2009/02/20/e4-and-rap/comment-page-1/#comment-576</link>
		<dc:creator>Kevin McGuire</dc:creator>
		<pubDate>Mon, 23 Feb 2009 21:31:23 +0000</pubDate>
		<guid isPermaLink="false">http://eclipsesource.com/blogs/?p=452#comment-576</guid>
		<description>Great to see that the e4 work has been investigated for use with RAP!

RAP does a good job of taking the UI written for the desktop and &quot;remote&#039;ing&quot; it to the web.  Perhaps though in this case the photo app&#039;s desktop &quot;shape&quot; is wrong for the web.

I&#039;ve been speaking to Erich and others recently about the notion that the workbench model should just describe the parts and their relationships, with then all visual decisions being made elsewhere.  Presently there&#039;s an odd mix of some decisions such as containment within sashes, sash positions, etc., being made in the model, and others such as fonts and colors made in CSS.  Then there&#039;s the problem that once you get below the part level, it&#039;s up the handler code to make the additional child widgets.  If instead that widget creation was declarative, then for the RAP case we could create an equivalent web control rather than &#039;web-ifying&#039; the Gallery widget.

So I&#039;m not sure if the right solution for RAP is:
1) Make a remote&#039;able Gallery widget (like you&#039;ve done for SWT)
2) Override the e4 modelled workbench renderers to produce web&#039;y things instead of producing SWT things that can be remote&#039;d (cut out the middle man)
3) Copy the e4 photo xmi, replacing the thumbnails part with something specific for the web
4) Go the full-on declarative route where the parts describe the widget tree declaratively and, like the workbench model renderers, produce the right widgets for desktop or web.</description>
		<content:encoded><![CDATA[<p>Great to see that the e4 work has been investigated for use with RAP!</p>
<p>RAP does a good job of taking the UI written for the desktop and &#8220;remote&#8217;ing&#8221; it to the web.  Perhaps though in this case the photo app&#8217;s desktop &#8220;shape&#8221; is wrong for the web.</p>
<p>I&#8217;ve been speaking to Erich and others recently about the notion that the workbench model should just describe the parts and their relationships, with then all visual decisions being made elsewhere.  Presently there&#8217;s an odd mix of some decisions such as containment within sashes, sash positions, etc., being made in the model, and others such as fonts and colors made in CSS.  Then there&#8217;s the problem that once you get below the part level, it&#8217;s up the handler code to make the additional child widgets.  If instead that widget creation was declarative, then for the RAP case we could create an equivalent web control rather than &#8216;web-ifying&#8217; the Gallery widget.</p>
<p>So I&#8217;m not sure if the right solution for RAP is:<br />
1) Make a remote&#8217;able Gallery widget (like you&#8217;ve done for SWT)<br />
2) Override the e4 modelled workbench renderers to produce web&#8217;y things instead of producing SWT things that can be remote&#8217;d (cut out the middle man)<br />
3) Copy the e4 photo xmi, replacing the thumbnails part with something specific for the web<br />
4) Go the full-on declarative route where the parts describe the widget tree declaratively and, like the workbench model renderers, produce the right widgets for desktop or web.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
