Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dali-dev] refactorings

Does anyone know if there is a way to set state on an emf adapter through the constructor?  It just doesn’t seem that emf expects you to have initial state, it expects you just get it via event notification.  I know you could just create adapters with construcotrs that take state, but this doesn’t fit the adaptorFactory pattern used in emf.

 

If my understanding on how to construct emf adapters is correct then I suggest that we add the API member() to PersistenceSourceRefElement.  This would return an org.eclipse.core.adapters.java.Member (this class and its hierarchy needs to be moved to another package).  In order to avoid constructing the java adapter with the corresponding Member, we would need this api.  We need the Member in order to update to and from the java.  Another reason for this api is that it would be needed by xml in the future.  Xml would need to know if an underlying java object exists for a particular attribute/field.  In order to display overrides in the UI we would probably need this information as well.

 

Karen

 

From: dali-dev-bounces@xxxxxxxxxxx [mailto:dali-dev-bounces@xxxxxxxxxxx] On Behalf Of Karen Moore
Sent: Monday, February 20, 2006 11:21 AM
To: dali-dev@xxxxxxxxxxx
Subject: [dali-dev] refactorings

 

Hi Christian and Markus,

 

Going ahead and sending this out to the entire team.

 

Just wanted to get the dialog started about what we’re planning on refactoring and how we are going to approach it.  You can add to this list and provide any feedback

 

  1. Change the java adapters to be an actual EMF adapter layer instead of a 1-1 relationship in the EMF core.
  2. Remove the setters for owned references such as Column. 
    1. Currently we have a setter, but this is only used during initialization and shouldn’t be used at any other time.  I know you had mentioned wanted to use null for these references as a way to determine the annotation existence.  I think a better way to do that is to have a flag on the object instead of using null.  I’m seeing problems right now with our UI expecting references like Basic column to never be null, but while the UI is populating, the model is still being initialized.  Right now we can’t initialize these kinds of references because they have to take a java adapter.  This would change if we make the java adapters real emf adapters.
  3. We need to do something to fix the undo problem that we have. Max entered bug #128626 for this and Dirk had talked about how to fix it at our planning meeting in January.
  4. UI bindings from the jsr220 project

 

I am curious how you plan on changing the orderBy adapter to be an EMF adapter in isolation.  It seems that we will have to have a lot of listeners on the emf core in order to do this.  Would we put these listeners at the orderBy level and then slowly move them up as we spread these changes throughout the model?

 

Karen

 

Back to the top