Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Eclipse Techs For GWT/Databinding"

(New page: == Target == The main goal of this project is to make the current Eclipse-Databinding project compiled into JavaScript using the GWT-compiler. There are the following things to consider: ...)
 
(Porting process)
Line 18: Line 18:
 
</ul>
 
</ul>
 
</li>
 
</li>
<li>Provide a replacement for Sytem.arraycopy (Maybe we could move them to a utility class?)</li>
+
<li>Provide a replacement for Sytem.arraycopy (Maybe we could move them to a utility class?). We should implement as much our own but if bigger classes are needed later on e.g. BigInteger, ... lending those classes from [http://harmony.apache.org/ Apache Harmony] might make sense.</li>
 
<li>Factor out not compilable code from Databinding and move the compilable code to base classes
 
<li>Factor out not compilable code from Databinding and move the compilable code to base classes
 
e.g. the whole auto-conversion stuff can't work in GWT (no BigDecimal, no NumberFormat, no DateFormat)
 
e.g. the whole auto-conversion stuff can't work in GWT (no BigDecimal, no NumberFormat, no DateFormat)
Line 24: Line 24:
 
<li>Create a set of scripts to automatically create GWT-Lib from Databinding-Sources</li>
 
<li>Create a set of scripts to automatically create GWT-Lib from Databinding-Sources</li>
 
<li>Explore whether there's a work-around client-package limitation</li>
 
<li>Explore whether there's a work-around client-package limitation</li>
 +
</ol>
 +
 +
== Additional things to consider ==
 +
 +
<ol>
 +
<li>There's no Reflection available in GWT and as a result of this no Beans-Support, we have to think about an other solution. As of now I see the following possibilities:
 +
<ul>
 +
<li>Get Core-EMF to compiled with GWT</li>
 +
<li>Provide our own small EMF (I called it PEMF for PoorEMF) for this it would be handy to have PropertyChange-Support from the java.beans package able. A possible solution is to copy them from [http://harmony.apache.org/ Apache Harmony] project</li>
 +
</ul>
 +
</li>
 
</ol>
 
</ol>

Revision as of 17:13, 2 October 2007

Target

The main goal of this project is to make the current Eclipse-Databinding project compiled into JavaScript using the GWT-compiler. There are the following things to consider:

  1. GWT only provides a very small class lib (e.g. only ArrayList is available no LinkedList, no System.arraycopy)
  2. There are no threads, ... a possible solution to this could be later on Google-Gears

Porting process

  1. Copy over the whole databinding stuff to the required .client-package:
    • org.eclipse.core.runtime => org.eclipse.core.runtime.gwt.client
    • org.eclipse.core.databinding => org.eclipse.core.databinding.gwt.client
  2. Provide a replacement for Sytem.arraycopy (Maybe we could move them to a utility class?). We should implement as much our own but if bigger classes are needed later on e.g. BigInteger, ... lending those classes from Apache Harmony might make sense.
  3. Factor out not compilable code from Databinding and move the compilable code to base classes e.g. the whole auto-conversion stuff can't work in GWT (no BigDecimal, no NumberFormat, no DateFormat)
  4. Create a set of scripts to automatically create GWT-Lib from Databinding-Sources
  5. Explore whether there's a work-around client-package limitation

Additional things to consider

  1. There's no Reflection available in GWT and as a result of this no Beans-Support, we have to think about an other solution. As of now I see the following possibilities:
    • Get Core-EMF to compiled with GWT
    • Provide our own small EMF (I called it PEMF for PoorEMF) for this it would be handy to have PropertyChange-Support from the java.beans package able. A possible solution is to copy them from Apache Harmony project

Back to the top