Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface)

[Ed Merks <merks@xxxxxxxxxx>]

Michael,

Assuming your data wasn't already part of a persistent model, you'd do something like this to convert it to a modeled instance for saving as well as the the inverse to process the modeled instance that's been loaded for you.

public EObject createMemento()
{
AbcRecord abcRecord = XyzFactory.eINSTANCE.createAbcRecord();
abcRecord.setSide(getSide());
abcRecord.getViewOrientation().putAll(viewOrientation);
return abcRecord;
}

public void handleMemento(EObject eObject)
{
AbcRecord abcRecord = (AbcRecord)eObject;
setSide(abcRecord.getSide());
viewOrientation.putAll(abcRecord.getViewOrientation());
}

Of course this is just one way of answering the question.  Another way to answer, and one more in keeping with the expectation that we must continue to maintain all existing APIs,  would be to show how the IMemento interface itself could be implemented as EObjects, i.e., so that "memento instanceof EObject" would be true. In this way, IMementos and IConfigurationElements could be manipulated in a uniform way, if there is a need for that.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)

Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>

Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/28/2008 09:00 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface)

Ed,

> Michael,
> 
> I think they could all be unified by EMF and thereby avoid YAMI. In 
> other words, I think all these interfaces could quite easily be 
> implemented by an underlying EMF model. Not only that, I expect that 
> YAMI itself could be implemented with an EMF model much like Ecore. 

Ok, let's do a simple validity test. How would an EMF based YAMI solution
replace the following IMemento code:

from org.eclipse.ui.internal.FastViewBar

     public void saveState(IMemento memento) {
         memento.putInteger(IWorkbenchConstants.TAG_FAST_VIEW_SIDE, getSide());

         Iterator iter = viewOrientation.keySet().iterator();
         while (iter.hasNext()) {
             String next = (String) iter.next();
             IMemento orientation = memento
                     .createChild(IWorkbenchConstants.TAG_FAST_VIEW_ORIENTATION);

             orientation.putString(IWorkbenchConstants.TAG_VIEW, next);
             orientation.putInteger(IWorkbenchConstants.TAG_POSITION,
                     ((Integer) viewOrientation.get(next)).intValue());
         }
     }

     public void restoreState(IMemento memento) {
         Integer bigInt;
         bigInt = memento.getInteger(IWorkbenchConstants.TAG_FAST_VIEW_SIDE);
         if (bigInt != null) {
             dock(bigInt.intValue());
         }

         IMemento[] orientations = memento
                 .getChildren(IWorkbenchConstants.TAG_FAST_VIEW_ORIENTATION);
         for (int i = 0; i < orientations.length; i++) {
             IMemento next = orientations[i];

             viewOrientation.put(next.getString(IWorkbenchConstants.TAG_VIEW),
                     next.getInteger(IWorkbenchConstants.TAG_POSITION));
         }
     }

Michael

> And 
> sadly, I expect that if we do YAMI, eventually we'll do YAMI Two, 
> because all good things appear to be followed by an even better sequel. 
> After all, folks are working on SDO 3.0 as we speak, though I'm not sure 
> anyone has done very many cool things with SDO 1.0, 2.0, 2.1, yet...
> 
> In all seriousness, I can only hope that as we rise from the depths of 
> hash maps and DOM, we learn lessons from them as well as from UML, XML 
> Schema, EMOF and SDO, before we do a sequel to any of those or to any of 
> the things you've listed below. If we can't do better do significantly 
> better than any of these, and especially if we have trouble 
> distinguishing a model from a meta model, then lets not bother with yet 
> another incarnation of these same things...
> 
> 
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
> 
> 
> Inactive hide details for Michael Scharf 
> <Michael.Scharf@xxxxxxxxxxxxx>Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>
> 
> 
>                         *Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>*
>                         Sent by:
>                         eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> 
>                         04/28/2008 05:26 PM
>                         Please respond to
>                         E4 developer list
>                         <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> 
> 		 
> 
> To
> 		 
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> 
> cc
> 		 
> 
> Subject
> 		 
> [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface)
> 
> 		 
> 
> 
> Eric Moffatt wrote:
>  > This is why I've been proposing YAMI (Yet Another Model Interface); if
>  > it were simply another API supporting the same functionality I'd be
>  > justifiably shot (I'd do it myself...;-). What I'm hoping to be able to
>  > do is to at least allow our users to have a 'common' api through which
>  > they can access the underlying information in a consistent manner; we
>  > make one more API but they see at least 3 -less-.
> 
> I am on the same page here. I think at least the following interfaces
> could be unified using YAMI (which are at least 5):
> 
>   org.eclipse.ui.IMemento
>   org.eclipse.core.runtime.IConfigurationElement
>   org.eclipse.jface.preference.IPreferenceStore
>   org.eclipse.jface.dialogs.IDialogSettings
>   org.eclipse.debug.core.ILaunchConfiguration
> 
> 
> Do you have a concrete proposal for YAMI? Or is it a
> vague idea?
> 
> Michael
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev