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/[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
905-413-3265 (t/l 313)
Michael Scharf
<[EMAIL PROTECTED]
indriver.com> To
Sent by: E4 developer list
eclipse-incubator <[EMAIL PROTECTED]
[EMAIL PROTECTED] rg>
clipse.org cc
Subject
04/28/2008 09:00 Re: [eclipse-incubator-e4-dev] YAMI
PM (Yet Another Model Interface)
Please respond to
E4 developer list
<eclipse-incubato
[EMAIL PROTECTED]
org>
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/[EMAIL PROTECTED]
> mailto: [EMAIL PROTECTED]
> 905-413-3265 (t/l 313)
>
>
> Inactive hide details for Michael Scharf
> <[EMAIL PROTECTED]>Michael Scharf
<[EMAIL PROTECTED]>
>
>
> *Michael Scharf <[EMAIL PROTECTED]>*
> Sent by:
> [EMAIL PROTECTED]
>
> 04/28/2008 05:26 PM
> Please respond to
> E4 developer list
> <[email protected]>
>
>
>
> To
>
> E4 developer list <[email protected]>
>
> 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
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
<<inline: graycol.gif>>
<<inline: pic28006.gif>>
<<inline: ecblank.gif>>
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
