Jump to: navigation, search

Difference between revisions of "COSMOSProjectRelationships"

(EMF)
Line 4: Line 4:
  
 
==EMF==
 
==EMF==
 +
EMF has two key aspects that are of interest to COSMOS.
 +
 +
The first is as a code generator, and in that context it is unlikely that we will use EMF. EMF is an excellent tool for creating the object model to back a user interface. By varying the options you can in fact have a complete editor template generated for you based on your input data model. However since COSMOS user interfaces that might consider this boiler plate approach will be browser based and would not be able to leverage that part of EMF code gen. In addition the data model is more or less assumed to be in memory with EMF and this is not a scalable approach for COSMOS. One could adjust the generation options to get down to what is in effect POJO model for snapshot view data, and provide an alternate EList implementation to deal with paging or faulting in data, but the effort to work around EMF to get very consistent generated code has to be balanced against the cost to simply write the code for the app server environment.
 +
 +
The second main feature of EMF is being able to get default serialization support via XMI, but as already noted, we would not need this serialization and we would likely not use the basic code generation.
 +
 +
Naturally this needs further deep design discussion, but at this point COSMOS need not leverage EMF.
 +
 
==TPTP==
 
==TPTP==
 
==WTP==
 
==WTP==

Revision as of 18:24, 13 November 2006

Eclipse Project Relationships

Here's a list of Eclipse projects we need to discuss

EMF

EMF has two key aspects that are of interest to COSMOS.

The first is as a code generator, and in that context it is unlikely that we will use EMF. EMF is an excellent tool for creating the object model to back a user interface. By varying the options you can in fact have a complete editor template generated for you based on your input data model. However since COSMOS user interfaces that might consider this boiler plate approach will be browser based and would not be able to leverage that part of EMF code gen. In addition the data model is more or less assumed to be in memory with EMF and this is not a scalable approach for COSMOS. One could adjust the generation options to get down to what is in effect POJO model for snapshot view data, and provide an alternate EList implementation to deal with paging or faulting in data, but the effort to work around EMF to get very consistent generated code has to be balanced against the cost to simply write the code for the app server environment.

The second main feature of EMF is being able to get default serialization support via XMI, but as already noted, we would not need this serialization and we would likely not use the basic code generation.

Naturally this needs further deep design discussion, but at this point COSMOS need not leverage EMF.

TPTP

WTP

BIRT

Minimum Project Requirements

JVM 1.5??