Home » Archived » XML Schema Definition (XSD) » Extending the XSD metamodel
| Extending the XSD metamodel [message #29572] |
Tue, 16 September 2003 13:45  |
 Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0072_01C37C2E.EF8B75E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I'd like to reuse the XSD metamodel by extending a few of the constructs =
(to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.
1.. Because this is an extension, writing out to .xsd format is no =
longer an option. Luckily there's .xmi. Is there an easy way to read =
and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.
2.. I'm running into a lot of difficulty with the item providers and =
(re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
collegues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.
Thanks in advance,
Randall Hauch
------=_NextPart_000_0072_01C37C2E.EF8B75E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'd like to reuse the XSD metamodel=20
by extending a few of the constructs (to add some new attributes), =
adding=20
some of my own, and then restricting the use of others. =
This is=20
very easy to do with other EMF generated metamodels. However, I'm =
running=20
into a few issues.</FONT></DIV>
<OL>
<LI><FONT face=3DArial size=3D2>Because this is an extension, =
writing out to=20
.xsd format is no longer an option. Luckily there's =
..xmi. Is=20
there an easy way to read and write to XMI but still use the=20
XSDResourceImpl (to keep all the benefits of that impl as the =
Resource)? =20
XSDResourceImpl doesn't extend XMIResourceImpl=20
or XMLResourceImpl.</FONT></LI>
<LI><FONT face=3DArial size=3D2>I'm running into a lot of difficulty =
with the item=20
providers and (re)using the resource bundle for the XSD. I'm =
using a=20
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory =
instances for=20
various metamodels. This approach has worked with the more =
than=20
dozen EMF-generated metamodels, including when we have models =
that use a=20
mixture of metamodels. This also works for a model when =
loaded from=20
an .xsd file (that is, a model that only uses the XSD metamodel), but =
as soon=20
as I open a model that uses my extended metamodel AND the XSD =
metamodel, then=20
the ItemProviders don't seem to find the labels or they don't find the =
icons. (What's even more bizarre is that they icons and labels =
do show=20
up correctly if the root object is an instance of an XSD metaclass, =
but if we=20
try to create an instance of an XSD metaclass under one of our own, =
then there=20
is a probem.) I suspect the problem is in my code, but is there=20
something different about how XSD does it's icons and string =
localization=20
(i18n) compared to normal EMF metamodels? One of my collegues is =
trying=20
to generate an Editor for our metamodel to see if our generated =
providers=20
work correctly that way.</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall =
Hauch</FONT></DIV></BODY></HTML>
------=_NextPart_000_0072_01C37C2E.EF8B75E0--
|
|
|
| Re: Extending the XSD metamodel [message #29597 is a reply to message #29572] |
Tue, 16 September 2003 18:20  |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C37C55.5DF94EF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
FYI: My colleague generated an EMF Editor for the new metamodel into =
brand-spankin' new Eclipse projects, and the generated editor is having =
the same problem (#2 below). So, I wonder if there's something about =
the highly-customized XSD metamodel that prevents extension. Thoughts? =
Suggestions? Help?
Thanks,
Randall
"Randall Hauch" <rhauch@metamatrix.com> wrote in message =
news:bk7462$gjg$1@eclipse.org...
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.
1.. Because this is an extension, writing out to .xsd format is no =
longer an option. Luckily there's .xmi. Is there an easy way to read =
and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item providers and =
(re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
colleagues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.
Thanks in advance,
Randall Hauch
------=_NextPart_000_000B_01C37C55.5DF94EF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>FYI: My colleague generated an =
EMF Editor for=20
the new metamodel into brand-spankin' new Eclipse projects, and the =
generated=20
editor is having the same problem (#2 below). So, I wonder if =
there's=20
something about the highly-customized XSD metamodel that prevents=20
extension. Thoughts? Suggestions? Help?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Randall Hauch" <<A=20
href=3D"mailto:rhauch@metamatrix.com">rhauch@metamatrix.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:bk7462$gjg$1@eclipse.org">news:bk7462$gjg$1@eclipse.org</A>.=
...</DIV>
<DIV><FONT face=3DArial size=3D2>I'd like to reuse the XSD metamodel=20
by extending a few of the constructs (to add some new =
attributes), adding=20
some of my own, and then restricting the use of =
others. This=20
is very easy to do with other EMF generated metamodels. However, =
I'm=20
running into a few issues.</FONT></DIV>
<OL>
<LI><FONT face=3DArial size=3D2>Because this is an extension, =
writing out=20
to .xsd format is no longer an option. Luckily there's=20
.xmi. Is there an easy way to read and write to XMI but =
still use=20
the XSDResourceImpl (to keep all the benefits of that impl as the=20
Resource)? XSDResourceImpl doesn't extend XMIResourceImpl=20
or XMLResourceImpl.</FONT>=20
<LI><FONT face=3DArial size=3D2>I'm running into a lot of difficulty =
with the=20
item providers and (re)using the resource bundle for the XSD. =
I'm=20
using a ComposedAdapterFactory to wrap the =
ItemProviderAdapterFactory=20
instances for various metamodels. This approach has =
worked with=20
the more than dozen EMF-generated metamodels, including when we =
have=20
models that use a mixture of metamodels. This also works =
for a=20
model when loaded from an .xsd file (that is, a model that only uses =
the XSD=20
metamodel), but as soon as I open a model that uses my extended =
metamodel=20
AND the XSD metamodel, then the ItemProviders don't seem to find the =
labels=20
or they don't find the icons. (What's even more bizarre is =
that they=20
icons and labels do show up correctly if the root object is an =
instance of=20
an XSD metaclass, but if we try to create an instance of an XSD =
metaclass=20
under one of our own, then there is a probem.) I suspect the =
problem=20
is in my code, but is there something different about how XSD does =
it's=20
icons and string localization (i18n) compared to normal EMF=20
metamodels? One of my colleagues is trying to generate an =
Editor for=20
our metamodel to see if our generated providers work correctly =
that=20
way.</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall=20
Hauch</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000B_01C37C55.5DF94EF0--
|
|
|
| Re: Extending the XSD metamodel [message #29615 is a reply to message #29572] |
Tue, 16 September 2003 18:23 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------DBBEEC0D874C54C959CA0B41
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Randall,
If you want an XMI serialization you'll need to pick a resource impl and
add in the stuff that's needed. Your best best is probably to mixin the
XMIResource interface and duplicate the necessary code; many of the
methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the
changeAttribute/changeReference methods in your derived classes, i.e.,
you could use non-schema namespace attributes and/or annotations to
serialize your extensions into well-formed XML Schema DOM...
The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does not
use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the
Edit plugin class. If this were properly in place, your extended model
would properly delegate icon/string fetching to the XSDEditPlugin. We
need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what to
suggest as an immediate workaround. Copying would certainly work for
the time being. Another approach is to hand code the delegation to the
XSDEditPlugin from your derived XyzEditPlugin...
Randall Hauch wrote:
> I'd like to reuse the XSD metamodel by extending a few of the
> constructs (to add some new attributes), adding some of my own, and
> then restricting the use of others. This is very easy to do with
> other EMF generated metamodels. However, I'm running into a few
> issues.
>
> 1. Because this is an extension, writing out to .xsd format is no
> longer an option. Luckily there's .xmi. Is there an easy way to
> read and write to XMI but still use the XSDResourceImpl (to keep
> all the benefits of that impl as the Resource)? XSDResourceImpl
> doesn't extend XMIResourceImpl or XMLResourceImpl.
> 2. I'm running into a lot of difficulty with the item providers and
> (re)using the resource bundle for the XSD. I'm using a
> ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
> instances for various metamodels. This approach has worked with
> the more than dozen EMF-generated metamodels, including when we
> have models that use a mixture of metamodels. This also works
> for a model when loaded from an .xsd file (that is, a model that
> only uses the XSD metamodel), but as soon as I open a model that
> uses my extended metamodel AND the XSD metamodel, then the
> ItemProviders don't seem to find the labels or they don't find
> the icons. (What's even more bizarre is that they icons and
> labels do show up correctly if the root object is an instance of
> an XSD metaclass, but if we try to create an instance of an XSD
> metaclass under one of our own, then there is a probem.) I
> suspect the problem is in my code, but is there something
> different about how XSD does it's icons and string localization
> (i18n) compared to normal EMF metamodels? One of my collegues is
> trying to generate an Editor for our metamodel to see if our
> generated providers work correctly that way.
>
> Thanks in advance, Randall Hauch
--------------DBBEEC0D874C54C959CA0B41
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Randall,
<p>If you want an XMI serialization you'll need to pick a resource impl
and add in the stuff that's needed. Your best best is probably to
mixin the XMIResource interface and duplicate the necessary code; many
of the methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the changeAttribute/changeReference
methods in your derived classes, i.e., you could use non-schema namespace
attributes and/or annotations to serialize your extensions into well-formed
XML Schema DOM...
<p>The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify
the Edit plugin class. If this were properly in place, your
extended model would properly delegate icon/string fetching to the XSDEditPlugin.
We need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what
to suggest as an immediate workaround. Copying would certainly work
for the time being. Another approach is to hand code the delegation
to the XSDEditPlugin from your derived XyzEditPlugin...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>I'd
like to reuse the XSD metamodel by extending a few of the constructs (to
add some new attributes), adding some of my own, and then restricting the
use of others. This is very easy to do with other EMF generated metamodels.
However, I'm running into a few issues.</font></font>
<ol>
<li>
<font face="Arial"><font size=-1>Because this is an extension, writing
out to .xsd format is no longer an option. Luckily there's .xmi.
Is there an easy way to read and write to XMI but still use the XSDResourceImpl
(to keep all the benefits of that impl as the Resource)? XSDResourceImpl
doesn't extend XMIResourceImpl or XMLResourceImpl.</font></font></li>
<li>
<font face="Arial"><font size=-1>I'm running into a lot of difficulty with
the item providers and (re)using the resource bundle for the XSD.
I'm using a ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
instances for various metamodels. This approach has worked with the
more than dozen EMF-generated metamodels, including when we have models
that use a mixture of metamodels. This also works for a model when
loaded from an .xsd file (that is, a model that only uses the XSD metamodel),
but as soon as I open a model that uses my extended metamodel AND the XSD
metamodel, then the ItemProviders don't seem to find the labels or they
don't find the icons. (What's even more bizarre is that they icons
and labels do show up correctly if the root object is an instance of an
XSD metaclass, but if we try to create an instance of an XSD metaclass
under one of our own, then there is a probem.) I suspect the problem
is in my code, but is there something different about how XSD does it's
icons and string localization (i18n) compared to normal EMF metamodels?
One of my collegues is trying to generate an Editor for our metamodel to
see if our generated providers work correctly that way.</font></font></li>
</ol>
<font face="Arial"><font size=-1>Thanks in advance,</font></font> <font face="Arial"><font size=-1>Randall
Hauch</font></font></blockquote>
</body>
</html>
--------------DBBEEC0D874C54C959CA0B41--
|
|
|
| Re: Extending the XSD metamodel [message #30042 is a reply to message #29615] |
Tue, 16 September 2003 18:45 |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C37C58.C39935B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks, Ed.
We re-implemented ResourceLocator and were delegating the 'getString' =
and getIcon' methods (just to name a few) - I thought we were doing that =
correctly. I'm wondering whether the XSDEditPlugin doesn't work with =
the ComposedAdapterFactory. Do you think creating a new =
ItemProviderAdapterFactory implementation might work, or is that part =
not so different from what EMF is now doing? Thoughts?
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675535.7B0AF53@ca.ibm.com...
Randall,=20
If you want an XMI serialization you'll need to pick a resource impl =
and add in the stuff that's needed. Your best best is probably to mixin =
the XMIResource interface and duplicate the necessary code; many of the =
methods could throw exceptions since they won't be used. Another =
approach is to serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference methods in your derived classes, i.e., =
you could use non-schema namespace attributes and/or annotations to =
serialize your extensions into well-formed XML Schema DOM...=20
The XSD item providers were generated a long time before our current =
generator support. They haven't been regenerated using that latest =
generator. So one of the problems is that the XSDEditPlugin does not =
use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the =
Edit plugin class. If this were properly in place, your extended model =
would properly delegate icon/string fetching to the XSDEditPlugin. We =
need to address this properly, but that will take significant time since =
we have so many things to do and so little time. I'm not sure what to =
suggest as an immediate workaround. Copying would certainly work for =
the time being. Another approach is to hand code the delegation to the =
XSDEditPlugin from your derived XyzEditPlugin...=20
=20
Randall Hauch wrote:=20
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.=20
1.. Because this is an extension, writing out to .xsd format is no =
longer an option. Luckily there's .xmi. Is there an easy way to read =
and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item providers =
and (re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
collegues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.=20
Thanks in advance, Randall Hauch
------=_NextPart_000_000F_01C37C58.C39935B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks, Ed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We re-implemented ResourceLocator and=20
were delegating the 'getString' and getIcon' methods (just to name =
a few) -=20
I thought we were doing that correctly. I'm wondering whether the=20
XSDEditPlugin doesn't work with the ComposedAdapterFactory. Do you =
think=20
creating a new ItemProviderAdapterFactory implementation might work, or =
is that=20
part not so different from what EMF is now doing? =
Thoughts?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.co=
m</A>...</DIV>Randall,=20
<P>If you want an XMI serialization you'll need to pick a resource =
impl and=20
add in the stuff that's needed. Your best best is probably to =
mixin the=20
XMIResource interface and duplicate the necessary code; many of the =
methods=20
could throw exceptions since they won't be used. Another =
approach is to=20
serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference=20
methods in your derived classes, i.e., you could use non-schema =
namespace=20
attributes and/or annotations to serialize your extensions into =
well-formed=20
XML Schema DOM...=20
<P>The XSD item providers were generated a long time before our =
current=20
generator support. They haven't been regenerated using that =
latest=20
generator. So one of the problems is that the XSDEditPlugin does =
not use=20
the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the=20
Edit plugin class. If this were properly in place, your =
extended=20
model would properly delegate icon/string fetching to the =
XSDEditPlugin. =20
We need to address this properly, but that will take significant time =
since we=20
have so many things to do and so little time. I'm not sure what =
to=20
suggest as an immediate workaround. Copying would certainly work =
for the=20
time being. Another approach is to hand code the delegation to =
the=20
XSDEditPlugin from your derived XyzEditPlugin... <BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I'd like to reuse the XSD =
metamodel by=20
extending a few of the constructs (to add some new attributes), =
adding some=20
of my own, and then restricting the use of others. This is =
very easy=20
to do with other EMF generated metamodels. However, I'm =
running into a=20
few issues.</FONT></FONT>=20
<OL>
<LI><FONT face=3DArial><FONT size=3D-1>Because this is an =
extension, writing=20
out to .xsd format is no longer an option. Luckily there's=20
.xmi. Is there an easy way to read and write to XMI but =
still use=20
the XSDResourceImpl (to keep all the benefits of that impl as the=20
Resource)? XSDResourceImpl doesn't extend XMIResourceImpl or =
XMLResourceImpl.</FONT></FONT>=20
<LI><FONT face=3DArial><FONT size=3D-1>I'm running into a lot of =
difficulty=20
with the item providers and (re)using the resource bundle for the=20
XSD. I'm using a ComposedAdapterFactory to wrap the=20
ItemProviderAdapterFactory instances for various metamodels. =
This=20
approach has worked with the more than dozen EMF-generated =
metamodels,=20
including when we have models that use a mixture of =
metamodels. This=20
also works for a model when loaded from an .xsd file (that is, a =
model=20
that only uses the XSD metamodel), but as soon as I open a model =
that uses=20
my extended metamodel AND the XSD metamodel, then the =
ItemProviders don't=20
seem to find the labels or they don't find the icons. =
(What's even=20
more bizarre is that they icons and labels do show up correctly if =
the=20
root object is an instance of an XSD metaclass, but if we try to =
create an=20
instance of an XSD metaclass under one of our own, then there is a =
probem.) I suspect the problem is in my code, but is there =
something=20
different about how XSD does it's icons and string localization =
(i18n)=20
compared to normal EMF metamodels? One of my collegues is =
trying to=20
generate an Editor for our metamodel to see if our generated =
providers=20
work correctly that way.</FONT></FONT> </LI></OL><FONT =
face=3DArial><FONT=20
size=3D-1>Thanks in advance,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>Randall =
Hauch</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_000F_01C37C58.C39935B0--
|
|
|
| Re: Extending the XSD metamodel [message #30065 is a reply to message #30042] |
Tue, 16 September 2003 19:09 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------F00DC4C90DE349D4E05A4107
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Randall,
Are your overriding delegatedGetImage/delegatedGetString in your
XyzEditPlugin? The item provider adapter factory implements
ComposeableAdapterFactory, so it should be okay. Putting the factories
in the right order is important, I assume your derived version comes
first...
Randall Hauch wrote:
> Thanks, Ed. We re-implemented ResourceLocator and were delegating the
> 'getString' and getIcon' methods (just to name a few) - I thought we
> were doing that correctly. I'm wondering whether the XSDEditPlugin
> doesn't work with the ComposedAdapterFactory. Do you think creating a
> new ItemProviderAdapterFactory implementation might work, or is that
> part not so different from what EMF is now doing? Thoughts?
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F675535.7B0AF53@ca.ibm.com...Randall,
>
> If you want an XMI serialization you'll need to pick a
> resource impl and add in the stuff that's needed. Your best
> best is probably to mixin the XMIResource interface and
> duplicate the necessary code; many of the methods could
> throw exceptions since they won't be used. Another approach
> is to serialize into the XSD's DOM by overriding the
> changeAttribute/changeReference methods in your derived
> classes, i.e., you could use non-schema namespace attributes
> and/or annotations to serialize your extensions into
> well-formed XML Schema DOM...
>
> The XSD item providers were generated a long time before our
> current generator support. They haven't been regenerated
> using that latest generator. So one of the problems is that
> the XSDEditPlugin does not use the EMFPlugin pattern and
> hence the XSD.genmodel doesn't specify the Edit plugin
> class. If this were properly in place, your extended model
> would properly delegate icon/string fetching to the
> XSDEditPlugin. We need to address this properly, but that
> will take significant time since we have so many things to
> do and so little time. I'm not sure what to suggest as an
> immediate workaround. Copying would certainly work for the
> time being. Another approach is to hand code the delegation
> to the XSDEditPlugin from your derived XyzEditPlugin...
>
>
> Randall Hauch wrote:
>
> > I'd like to reuse the XSD metamodel by extending a few of
> > the constructs (to add some new attributes), adding some
> > of my own, and then restricting the use of others. This
> > is very easy to do with other EMF generated metamodels.
> > However, I'm running into a few issues.
> >
> > 1. Because this is an extension, writing out to .xsd
> > format is no longer an option. Luckily there's
> > .xmi. Is there an easy way to read and write to XMI
> > but still use the XSDResourceImpl (to keep all the
> > benefits of that impl as the Resource)?
> > XSDResourceImpl doesn't extend XMIResourceImpl or
> > XMLResourceImpl.
> > 2. I'm running into a lot of difficulty with the item
> > providers and (re)using the resource bundle for the
> > XSD. I'm using a ComposedAdapterFactory to wrap the
> > ItemProviderAdapterFactory instances for various
> > metamodels. This approach has worked with the more
> > than dozen EMF-generated metamodels, including when
> > we have models that use a mixture of metamodels.
> > This also works for a model when loaded from an .xsd
> > file (that is, a model that only uses the XSD
> > metamodel), but as soon as I open a model that uses
> > my extended metamodel AND the XSD metamodel, then the
> > ItemProviders don't seem to find the labels or they
> > don't find the icons. (What's even more bizarre is
> > that they icons and labels do show up correctly if
> > the root object is an instance of an XSD metaclass,
> > but if we try to create an instance of an XSD
> > metaclass under one of our own, then there is a
> > probem.) I suspect the problem is in my code, but is
> > there something different about how XSD does it's
> > icons and string localization (i18n) compared to
> > normal EMF metamodels? One of my collegues is trying
> > to generate an Editor for our metamodel to see if our
> > generated providers work correctly that way.
> >
> > Thanks in advance, Randall Hauch
>
--------------F00DC4C90DE349D4E05A4107
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Randall,
<p>Are your overriding delegatedGetImage/delegatedGetString in your XyzEditPlugin?
The item provider adapter factory implements ComposeableAdapterFactory,
so it should be okay. Putting the factories in the right order is
important, I assume your derived version comes first...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Thanks, Ed.</font></font> <font face="Arial"><font size=-1>We
re-implemented ResourceLocator and were delegating the 'getString' and
getIcon' methods (just to name a few) - I thought we were doing that correctly.
I'm wondering whether the XSDEditPlugin doesn't work with the ComposedAdapterFactory.
Do you think creating a new ItemProviderAdapterFactory implementation might
work, or is that part not so different from what EMF is now doing?
Thoughts?</font></font>
<blockquote dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
in message <a href="news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.com</a>...Randall,
<p>If you want an XMI serialization you'll need to pick a resource impl
and add in the stuff that's needed. Your best best is probably to
mixin the XMIResource interface and duplicate the necessary code; many
of the methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the changeAttribute/changeReference
methods in your derived classes, i.e., you could use non-schema namespace
attributes and/or annotations to serialize your extensions into well-formed
XML Schema DOM...
<p>The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify
the Edit plugin class. If this were properly in place, your
extended model would properly delegate icon/string fetching to the XSDEditPlugin.
We need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what
to suggest as an immediate workaround. Copying would certainly work
for the time being. Another approach is to hand code the delegation
to the XSDEditPlugin from your derived XyzEditPlugin...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I'd
like to reuse the XSD metamodel by extending a few of the constructs (to
add some new attributes), adding some of my own, and then restricting the
use of others. This is very easy to do with other EMF generated metamodels.
However, I'm running into a few issues.</font></font>
<ol>
<li>
<font face="Arial"><font size=-1>Because this is an extension, writing
out to .xsd format is no longer an option. Luckily there's .xmi.
Is there an easy way to read and write to XMI but still use the XSDResourceImpl
(to keep all the benefits of that impl as the Resource)? XSDResourceImpl
doesn't extend XMIResourceImpl or XMLResourceImpl.</font></font></li>
<li>
<font face="Arial"><font size=-1>I'm running into a lot of difficulty with
the item providers and (re)using the resource bundle for the XSD.
I'm using a ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
instances for various metamodels. This approach has worked with the
more than dozen EMF-generated metamodels, including when we have models
that use a mixture of metamodels. This also works for a model when
loaded from an .xsd file (that is, a model that only uses the XSD metamodel),
but as soon as I open a model that uses my extended metamodel AND the XSD
metamodel, then the ItemProviders don't seem to find the labels or they
don't find the icons. (What's even more bizarre is that they icons
and labels do show up correctly if the root object is an instance of an
XSD metaclass, but if we try to create an instance of an XSD metaclass
under one of our own, then there is a probem.) I suspect the problem
is in my code, but is there something different about how XSD does it's
icons and string localization (i18n) compared to normal EMF metamodels?
One of my collegues is trying to generate an Editor for our metamodel to
see if our generated providers work correctly that way.</font></font></li>
</ol>
<font face="Arial"><font size=-1>Thanks in advance,</font></font> <font face="Arial"><font size=-1>Randall
Hauch</font></font></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------F00DC4C90DE349D4E05A4107--
|
|
|
| Re: Extending the XSD metamodel [message #30102 is a reply to message #30065] |
Mon, 22 September 2003 13:49 |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00E7_01C380E6.6645A6E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Actually, I overrode the 'getResourceLocator()' method in the =
XyzEditPlugin to return a new implementation that looks locally and then =
delegates if required. I didn't see the those methods when I was =
implementing our code. Is it better to override the 'delegatedGetImage' =
and 'delegatedGetString' methods?
One problem I ran into was that for a while I was using the =
XSDPlugin.getResourceLocator(), but have changed that to be =
XSDEditPlugin.eINSTANCE.getResourceLocator().
Another thing that was throwing us was that XSD appears to put more =
meaningful information in the command's label. We were use to the =
typical generated code having label's like "Set" or "Create", so we =
ended up looking at the result of the command and having our UI =
providers use those object's item provider to get the label and icon.
The final thing was that the standard XMIResourceImpl functionality of =
reading and writing XMI streams does not seem to be compatible. What we =
tried to do was write out an XSD model as XMI and then back in. =
XMIResourceImpl simply writes out all feature values to the stream =
(except for those that match the default), while reading merely tries to =
call the setter for every value it finds in the XMI. Up until extending =
XSD, we've used so very few unsettable features that we've never seen =
this behavior (despite our automated test framework ;-(
We did some refactoring of our code, and are in the middle of getting =
our regression tests to work again. But we should be a lot closer, =
although I think our refactoring will probably end up with still a =
couple of open issues.
Randall
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675FF4.8653F491@ca.ibm.com...
Randall,=20
Are your overriding delegatedGetImage/delegatedGetString in your =
XyzEditPlugin? The item provider adapter factory implements =
ComposeableAdapterFactory, so it should be okay. Putting the factories =
in the right order is important, I assume your derived version comes =
first...=20
=20
Randall Hauch wrote:=20
Thanks, Ed. We re-implemented ResourceLocator and were delegating =
the 'getString' and getIcon' methods (just to name a few) - I thought we =
were doing that correctly. I'm wondering whether the XSDEditPlugin =
doesn't work with the ComposedAdapterFactory. Do you think creating a =
new ItemProviderAdapterFactory implementation might work, or is that =
part not so different from what EMF is now doing? Thoughts? =20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675535.7B0AF53@ca.ibm.com...Randall,=20
If you want an XMI serialization you'll need to pick a resource =
impl and add in the stuff that's needed. Your best best is probably to =
mixin the XMIResource interface and duplicate the necessary code; many =
of the methods could throw exceptions since they won't be used. Another =
approach is to serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference methods in your derived classes, i.e., =
you could use non-schema namespace attributes and/or annotations to =
serialize your extensions into well-formed XML Schema DOM...=20
The XSD item providers were generated a long time before our =
current generator support. They haven't been regenerated using that =
latest generator. So one of the problems is that the XSDEditPlugin does =
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify =
the Edit plugin class. If this were properly in place, your extended =
model would properly delegate icon/string fetching to the XSDEditPlugin. =
We need to address this properly, but that will take significant time =
since we have so many things to do and so little time. I'm not sure =
what to suggest as an immediate workaround. Copying would certainly =
work for the time being. Another approach is to hand code the =
delegation to the XSDEditPlugin from your derived XyzEditPlugin...=20
=20
Randall Hauch wrote:=20
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.=20
1.. Because this is an extension, writing out to .xsd format =
is no longer an option. Luckily there's .xmi. Is there an easy way to =
read and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item =
providers and (re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
collegues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.=20
Thanks in advance, Randall Hauch
------=_NextPart_000_00E7_01C380E6.6645A6E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3DArial size=3D2>Actually, I overrode the =
'getResourceLocator()'=20
method in the XyzEditPlugin to return a new implementation that looks =
locally=20
and then delegates if required. I didn't see the those =
methods when I=20
was implementing our code. Is it better to override the=20
'delegatedGetImage' and 'delegatedGetString' methods?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>One problem I ran into was that for a =
while I was=20
using the XSDPlugin.getResourceLocator(), but have changed that to be=20
XSDEditPlugin.eINSTANCE.getResourceLocator().</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another thing that was throwing us was =
that XSD=20
appears to put more meaningful information in the command's label. =
We were=20
use to the typical generated code having label's like "Set" or =
"Create", so=20
we ended up looking at the result of the command and having our UI =
providers use=20
those object's item provider to get the label and icon.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The final thing was that the standard=20
XMIResourceImpl functionality of reading and writing XMI streams does =
not seem=20
to be compatible. What we tried to do was write out an XSD =
model as=20
XMI and then back in. XMIResourceImpl simply writes out =
all=20
feature values to the stream (except for those that match the default), =
while=20
reading merely tries to call the setter for every value it =
finds in=20
the XMI. Up until extending XSD, we've used so very few unsettable =
features that we've never seen this behavior (despite our automated test =
framework ;-(</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We did some refactoring of our code, =
and are in the=20
middle of getting our regression tests to work again. But we =
should be a=20
lot closer, although I think our refactoring will probably end up with =
still a=20
couple of open issues.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall</FONT></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675FF4.8653F491@ca.ibm.com">news:3F675FF4.8653F491@ca.ibm.=
com</A>...</DIV>Randall,=20
<P>Are your overriding delegatedGetImage/delegatedGetString in your=20
XyzEditPlugin? The item provider adapter factory implements=20
ComposeableAdapterFactory, so it should be okay. Putting the =
factories=20
in the right order is important, I assume your derived version comes =
first...=20
<BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"> <FONT face=3DArial><FONT =
size=3D-1>Thanks,=20
Ed.</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>We =
re-implemented=20
ResourceLocator and were delegating the 'getString' and getIcon' =
methods=20
(just to name a few) - I thought we were doing that correctly. =
I'm=20
wondering whether the XSDEditPlugin doesn't work with the=20
ComposedAdapterFactory. Do you think creating a new=20
ItemProviderAdapterFactory implementation might work, or is that =
part not so=20
different from what EMF is now doing? =
Thoughts?</FONT></FONT> =20
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed=20
Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.co=
m</A>...Randall,=20
<P>If you want an XMI serialization you'll need to pick a resource =
impl=20
and add in the stuff that's needed. Your best best is =
probably to=20
mixin the XMIResource interface and duplicate the necessary code; =
many of=20
the methods could throw exceptions since they won't be used. =
Another=20
approach is to serialize into the XSD's DOM by overriding the=20
changeAttribute/changeReference methods in your derived classes, =
i.e., you=20
could use non-schema namespace attributes and/or annotations to =
serialize=20
your extensions into well-formed XML Schema DOM...=20
<P>The XSD item providers were generated a long time before our =
current=20
generator support. They haven't been regenerated using that =
latest=20
generator. So one of the problems is that the XSDEditPlugin =
does not=20
use the EMFPlugin pattern and hence the XSD.genmodel doesn't =
specify the=20
Edit plugin class. If this were properly in place, =
your=20
extended model would properly delegate icon/string fetching to the =
XSDEditPlugin. We need to address this properly, but that =
will take=20
significant time since we have so many things to do and so little=20
time. I'm not sure what to suggest as an immediate =
workaround. =20
Copying would certainly work for the time being. Another =
approach is=20
to hand code the delegation to the XSDEditPlugin from your derived =
XyzEditPlugin... <BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I'd like to reuse the XSD =
metamodel by=20
extending a few of the constructs (to add some new attributes), =
adding=20
some of my own, and then restricting the use of others. =
This is=20
very easy to do with other EMF generated metamodels. =
However, I'm=20
running into a few issues.</FONT></FONT>=20
<OL>
<LI><FONT face=3DArial><FONT size=3D-1>Because this is an =
extension,=20
writing out to .xsd format is no longer an option. =
Luckily=20
there's .xmi. Is there an easy way to read and write to =
XMI but=20
still use the XSDResourceImpl (to keep all the benefits of =
that impl=20
as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl=20
or XMLResourceImpl.</FONT></FONT>=20
<LI><FONT face=3DArial><FONT size=3D-1>I'm running into a lot =
of=20
difficulty with the item providers and (re)using the resource =
bundle=20
for the XSD. I'm using a ComposedAdapterFactory to wrap =
the=20
ItemProviderAdapterFactory instances for various =
metamodels. =20
This approach has worked with the more than dozen =
EMF-generated=20
metamodels, including when we have models that use a mixture =
of=20
metamodels. This also works for a model when loaded from =
an .xsd=20
file (that is, a model that only uses the XSD metamodel), but =
as soon=20
as I open a model that uses my extended metamodel AND the XSD=20
metamodel, then the ItemProviders don't seem to find the =
labels or=20
they don't find the icons. (What's even more bizarre is =
that=20
they icons and labels do show up correctly if the root object =
is an=20
instance of an XSD metaclass, but if we try to create an =
instance of=20
an XSD metaclass under one of our own, then there is a =
probem.) =20
I suspect the problem is in my code, but is there something =
different=20
about how XSD does it's icons and string localization (i18n) =
compared=20
to normal EMF metamodels? One of my collegues is trying =
to=20
generate an Editor for our metamodel to see if our generated =
providers=20
work correctly that way.</FONT></FONT> </LI></OL><FONT =
face=3DArial><FONT=20
size=3D-1>Thanks in advance,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>Randall=20
Hauch</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BLOCKQUOTE></=
BODY></HTML>
------=_NextPart_000_00E7_01C380E6.6645A6E0--
|
|
|
| Re: Extending the XSD metamodel [message #578222 is a reply to message #29572] |
Tue, 16 September 2003 18:20 |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C37C55.5DF94EF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
FYI: My colleague generated an EMF Editor for the new metamodel into =
brand-spankin' new Eclipse projects, and the generated editor is having =
the same problem (#2 below). So, I wonder if there's something about =
the highly-customized XSD metamodel that prevents extension. Thoughts? =
Suggestions? Help?
Thanks,
Randall
"Randall Hauch" <rhauch@metamatrix.com> wrote in message =
news:bk7462$gjg$1@eclipse.org...
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.
1.. Because this is an extension, writing out to .xsd format is no =
longer an option. Luckily there's .xmi. Is there an easy way to read =
and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item providers and =
(re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
colleagues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.
Thanks in advance,
Randall Hauch
------=_NextPart_000_000B_01C37C55.5DF94EF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>FYI: My colleague generated an =
EMF Editor for=20
the new metamodel into brand-spankin' new Eclipse projects, and the =
generated=20
editor is having the same problem (#2 below). So, I wonder if =
there's=20
something about the highly-customized XSD metamodel that prevents=20
extension. Thoughts? Suggestions? Help?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Randall Hauch" <<A=20
href=3D"mailto:rhauch@metamatrix.com">rhauch@metamatrix.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:bk7462$gjg$1@eclipse.org">news:bk7462$gjg$1@eclipse.org</A>.=
...</DIV>
<DIV><FONT face=3DArial size=3D2>I'd like to reuse the XSD metamodel=20
by extending a few of the constructs (to add some new =
attributes), adding=20
some of my own, and then restricting the use of =
others. This=20
is very easy to do with other EMF generated metamodels. However, =
I'm=20
running into a few issues.</FONT></DIV>
<OL>
<LI><FONT face=3DArial size=3D2>Because this is an extension, =
writing out=20
to .xsd format is no longer an option. Luckily there's=20
.xmi. Is there an easy way to read and write to XMI but =
still use=20
the XSDResourceImpl (to keep all the benefits of that impl as the=20
Resource)? XSDResourceImpl doesn't extend XMIResourceImpl=20
or XMLResourceImpl.</FONT>=20
<LI><FONT face=3DArial size=3D2>I'm running into a lot of difficulty =
with the=20
item providers and (re)using the resource bundle for the XSD. =
I'm=20
using a ComposedAdapterFactory to wrap the =
ItemProviderAdapterFactory=20
instances for various metamodels. This approach has =
worked with=20
the more than dozen EMF-generated metamodels, including when we =
have=20
models that use a mixture of metamodels. This also works =
for a=20
model when loaded from an .xsd file (that is, a model that only uses =
the XSD=20
metamodel), but as soon as I open a model that uses my extended =
metamodel=20
AND the XSD metamodel, then the ItemProviders don't seem to find the =
labels=20
or they don't find the icons. (What's even more bizarre is =
that they=20
icons and labels do show up correctly if the root object is an =
instance of=20
an XSD metaclass, but if we try to create an instance of an XSD =
metaclass=20
under one of our own, then there is a probem.) I suspect the =
problem=20
is in my code, but is there something different about how XSD does =
it's=20
icons and string localization (i18n) compared to normal EMF=20
metamodels? One of my colleagues is trying to generate an =
Editor for=20
our metamodel to see if our generated providers work correctly =
that=20
way.</FONT></LI></OL>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall=20
Hauch</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000B_01C37C55.5DF94EF0--
|
|
|
| Re: Extending the XSD metamodel [message #578251 is a reply to message #29572] |
Tue, 16 September 2003 18:23 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------DBBEEC0D874C54C959CA0B41
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Randall,
If you want an XMI serialization you'll need to pick a resource impl and
add in the stuff that's needed. Your best best is probably to mixin the
XMIResource interface and duplicate the necessary code; many of the
methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the
changeAttribute/changeReference methods in your derived classes, i.e.,
you could use non-schema namespace attributes and/or annotations to
serialize your extensions into well-formed XML Schema DOM...
The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does not
use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the
Edit plugin class. If this were properly in place, your extended model
would properly delegate icon/string fetching to the XSDEditPlugin. We
need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what to
suggest as an immediate workaround. Copying would certainly work for
the time being. Another approach is to hand code the delegation to the
XSDEditPlugin from your derived XyzEditPlugin...
Randall Hauch wrote:
> I'd like to reuse the XSD metamodel by extending a few of the
> constructs (to add some new attributes), adding some of my own, and
> then restricting the use of others. This is very easy to do with
> other EMF generated metamodels. However, I'm running into a few
> issues.
>
> 1. Because this is an extension, writing out to .xsd format is no
> longer an option. Luckily there's .xmi. Is there an easy way to
> read and write to XMI but still use the XSDResourceImpl (to keep
> all the benefits of that impl as the Resource)? XSDResourceImpl
> doesn't extend XMIResourceImpl or XMLResourceImpl.
> 2. I'm running into a lot of difficulty with the item providers and
> (re)using the resource bundle for the XSD. I'm using a
> ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
> instances for various metamodels. This approach has worked with
> the more than dozen EMF-generated metamodels, including when we
> have models that use a mixture of metamodels. This also works
> for a model when loaded from an .xsd file (that is, a model that
> only uses the XSD metamodel), but as soon as I open a model that
> uses my extended metamodel AND the XSD metamodel, then the
> ItemProviders don't seem to find the labels or they don't find
> the icons. (What's even more bizarre is that they icons and
> labels do show up correctly if the root object is an instance of
> an XSD metaclass, but if we try to create an instance of an XSD
> metaclass under one of our own, then there is a probem.) I
> suspect the problem is in my code, but is there something
> different about how XSD does it's icons and string localization
> (i18n) compared to normal EMF metamodels? One of my collegues is
> trying to generate an Editor for our metamodel to see if our
> generated providers work correctly that way.
>
> Thanks in advance, Randall Hauch
--------------DBBEEC0D874C54C959CA0B41
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Randall,
<p>If you want an XMI serialization you'll need to pick a resource impl
and add in the stuff that's needed. Your best best is probably to
mixin the XMIResource interface and duplicate the necessary code; many
of the methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the changeAttribute/changeReference
methods in your derived classes, i.e., you could use non-schema namespace
attributes and/or annotations to serialize your extensions into well-formed
XML Schema DOM...
<p>The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify
the Edit plugin class. If this were properly in place, your
extended model would properly delegate icon/string fetching to the XSDEditPlugin.
We need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what
to suggest as an immediate workaround. Copying would certainly work
for the time being. Another approach is to hand code the delegation
to the XSDEditPlugin from your derived XyzEditPlugin...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>I'd
like to reuse the XSD metamodel by extending a few of the constructs (to
add some new attributes), adding some of my own, and then restricting the
use of others. This is very easy to do with other EMF generated metamodels.
However, I'm running into a few issues.</font></font>
<ol>
<li>
<font face="Arial"><font size=-1>Because this is an extension, writing
out to .xsd format is no longer an option. Luckily there's .xmi.
Is there an easy way to read and write to XMI but still use the XSDResourceImpl
(to keep all the benefits of that impl as the Resource)? XSDResourceImpl
doesn't extend XMIResourceImpl or XMLResourceImpl.</font></font></li>
<li>
<font face="Arial"><font size=-1>I'm running into a lot of difficulty with
the item providers and (re)using the resource bundle for the XSD.
I'm using a ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
instances for various metamodels. This approach has worked with the
more than dozen EMF-generated metamodels, including when we have models
that use a mixture of metamodels. This also works for a model when
loaded from an .xsd file (that is, a model that only uses the XSD metamodel),
but as soon as I open a model that uses my extended metamodel AND the XSD
metamodel, then the ItemProviders don't seem to find the labels or they
don't find the icons. (What's even more bizarre is that they icons
and labels do show up correctly if the root object is an instance of an
XSD metaclass, but if we try to create an instance of an XSD metaclass
under one of our own, then there is a probem.) I suspect the problem
is in my code, but is there something different about how XSD does it's
icons and string localization (i18n) compared to normal EMF metamodels?
One of my collegues is trying to generate an Editor for our metamodel to
see if our generated providers work correctly that way.</font></font></li>
</ol>
<font face="Arial"><font size=-1>Thanks in advance,</font></font> <font face="Arial"><font size=-1>Randall
Hauch</font></font></blockquote>
</body>
</html>
--------------DBBEEC0D874C54C959CA0B41--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Extending the XSD metamodel [message #578267 is a reply to message #29615] |
Tue, 16 September 2003 18:45 |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C37C58.C39935B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks, Ed.
We re-implemented ResourceLocator and were delegating the 'getString' =
and getIcon' methods (just to name a few) - I thought we were doing that =
correctly. I'm wondering whether the XSDEditPlugin doesn't work with =
the ComposedAdapterFactory. Do you think creating a new =
ItemProviderAdapterFactory implementation might work, or is that part =
not so different from what EMF is now doing? Thoughts?
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675535.7B0AF53@ca.ibm.com...
Randall,=20
If you want an XMI serialization you'll need to pick a resource impl =
and add in the stuff that's needed. Your best best is probably to mixin =
the XMIResource interface and duplicate the necessary code; many of the =
methods could throw exceptions since they won't be used. Another =
approach is to serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference methods in your derived classes, i.e., =
you could use non-schema namespace attributes and/or annotations to =
serialize your extensions into well-formed XML Schema DOM...=20
The XSD item providers were generated a long time before our current =
generator support. They haven't been regenerated using that latest =
generator. So one of the problems is that the XSDEditPlugin does not =
use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the =
Edit plugin class. If this were properly in place, your extended model =
would properly delegate icon/string fetching to the XSDEditPlugin. We =
need to address this properly, but that will take significant time since =
we have so many things to do and so little time. I'm not sure what to =
suggest as an immediate workaround. Copying would certainly work for =
the time being. Another approach is to hand code the delegation to the =
XSDEditPlugin from your derived XyzEditPlugin...=20
=20
Randall Hauch wrote:=20
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.=20
1.. Because this is an extension, writing out to .xsd format is no =
longer an option. Luckily there's .xmi. Is there an easy way to read =
and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item providers =
and (re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
collegues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.=20
Thanks in advance, Randall Hauch
------=_NextPart_000_000F_01C37C58.C39935B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks, Ed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We re-implemented ResourceLocator and=20
were delegating the 'getString' and getIcon' methods (just to name =
a few) -=20
I thought we were doing that correctly. I'm wondering whether the=20
XSDEditPlugin doesn't work with the ComposedAdapterFactory. Do you =
think=20
creating a new ItemProviderAdapterFactory implementation might work, or =
is that=20
part not so different from what EMF is now doing? =
Thoughts?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.co=
m</A>...</DIV>Randall,=20
<P>If you want an XMI serialization you'll need to pick a resource =
impl and=20
add in the stuff that's needed. Your best best is probably to =
mixin the=20
XMIResource interface and duplicate the necessary code; many of the =
methods=20
could throw exceptions since they won't be used. Another =
approach is to=20
serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference=20
methods in your derived classes, i.e., you could use non-schema =
namespace=20
attributes and/or annotations to serialize your extensions into =
well-formed=20
XML Schema DOM...=20
<P>The XSD item providers were generated a long time before our =
current=20
generator support. They haven't been regenerated using that =
latest=20
generator. So one of the problems is that the XSDEditPlugin does =
not use=20
the EMFPlugin pattern and hence the XSD.genmodel doesn't specify the=20
Edit plugin class. If this were properly in place, your =
extended=20
model would properly delegate icon/string fetching to the =
XSDEditPlugin. =20
We need to address this properly, but that will take significant time =
since we=20
have so many things to do and so little time. I'm not sure what =
to=20
suggest as an immediate workaround. Copying would certainly work =
for the=20
time being. Another approach is to hand code the delegation to =
the=20
XSDEditPlugin from your derived XyzEditPlugin... <BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I'd like to reuse the XSD =
metamodel by=20
extending a few of the constructs (to add some new attributes), =
adding some=20
of my own, and then restricting the use of others. This is =
very easy=20
to do with other EMF generated metamodels. However, I'm =
running into a=20
few issues.</FONT></FONT>=20
<OL>
<LI><FONT face=3DArial><FONT size=3D-1>Because this is an =
extension, writing=20
out to .xsd format is no longer an option. Luckily there's=20
.xmi. Is there an easy way to read and write to XMI but =
still use=20
the XSDResourceImpl (to keep all the benefits of that impl as the=20
Resource)? XSDResourceImpl doesn't extend XMIResourceImpl or =
XMLResourceImpl.</FONT></FONT>=20
<LI><FONT face=3DArial><FONT size=3D-1>I'm running into a lot of =
difficulty=20
with the item providers and (re)using the resource bundle for the=20
XSD. I'm using a ComposedAdapterFactory to wrap the=20
ItemProviderAdapterFactory instances for various metamodels. =
This=20
approach has worked with the more than dozen EMF-generated =
metamodels,=20
including when we have models that use a mixture of =
metamodels. This=20
also works for a model when loaded from an .xsd file (that is, a =
model=20
that only uses the XSD metamodel), but as soon as I open a model =
that uses=20
my extended metamodel AND the XSD metamodel, then the =
ItemProviders don't=20
seem to find the labels or they don't find the icons. =
(What's even=20
more bizarre is that they icons and labels do show up correctly if =
the=20
root object is an instance of an XSD metaclass, but if we try to =
create an=20
instance of an XSD metaclass under one of our own, then there is a =
probem.) I suspect the problem is in my code, but is there =
something=20
different about how XSD does it's icons and string localization =
(i18n)=20
compared to normal EMF metamodels? One of my collegues is =
trying to=20
generate an Editor for our metamodel to see if our generated =
providers=20
work correctly that way.</FONT></FONT> </LI></OL><FONT =
face=3DArial><FONT=20
size=3D-1>Thanks in advance,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>Randall =
Hauch</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_000F_01C37C58.C39935B0--
|
|
|
| Re: Extending the XSD metamodel [message #578303 is a reply to message #30042] |
Tue, 16 September 2003 19:09 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------F00DC4C90DE349D4E05A4107
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Randall,
Are your overriding delegatedGetImage/delegatedGetString in your
XyzEditPlugin? The item provider adapter factory implements
ComposeableAdapterFactory, so it should be okay. Putting the factories
in the right order is important, I assume your derived version comes
first...
Randall Hauch wrote:
> Thanks, Ed. We re-implemented ResourceLocator and were delegating the
> 'getString' and getIcon' methods (just to name a few) - I thought we
> were doing that correctly. I'm wondering whether the XSDEditPlugin
> doesn't work with the ComposedAdapterFactory. Do you think creating a
> new ItemProviderAdapterFactory implementation might work, or is that
> part not so different from what EMF is now doing? Thoughts?
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F675535.7B0AF53@ca.ibm.com...Randall,
>
> If you want an XMI serialization you'll need to pick a
> resource impl and add in the stuff that's needed. Your best
> best is probably to mixin the XMIResource interface and
> duplicate the necessary code; many of the methods could
> throw exceptions since they won't be used. Another approach
> is to serialize into the XSD's DOM by overriding the
> changeAttribute/changeReference methods in your derived
> classes, i.e., you could use non-schema namespace attributes
> and/or annotations to serialize your extensions into
> well-formed XML Schema DOM...
>
> The XSD item providers were generated a long time before our
> current generator support. They haven't been regenerated
> using that latest generator. So one of the problems is that
> the XSDEditPlugin does not use the EMFPlugin pattern and
> hence the XSD.genmodel doesn't specify the Edit plugin
> class. If this were properly in place, your extended model
> would properly delegate icon/string fetching to the
> XSDEditPlugin. We need to address this properly, but that
> will take significant time since we have so many things to
> do and so little time. I'm not sure what to suggest as an
> immediate workaround. Copying would certainly work for the
> time being. Another approach is to hand code the delegation
> to the XSDEditPlugin from your derived XyzEditPlugin...
>
>
> Randall Hauch wrote:
>
> > I'd like to reuse the XSD metamodel by extending a few of
> > the constructs (to add some new attributes), adding some
> > of my own, and then restricting the use of others. This
> > is very easy to do with other EMF generated metamodels.
> > However, I'm running into a few issues.
> >
> > 1. Because this is an extension, writing out to .xsd
> > format is no longer an option. Luckily there's
> > .xmi. Is there an easy way to read and write to XMI
> > but still use the XSDResourceImpl (to keep all the
> > benefits of that impl as the Resource)?
> > XSDResourceImpl doesn't extend XMIResourceImpl or
> > XMLResourceImpl.
> > 2. I'm running into a lot of difficulty with the item
> > providers and (re)using the resource bundle for the
> > XSD. I'm using a ComposedAdapterFactory to wrap the
> > ItemProviderAdapterFactory instances for various
> > metamodels. This approach has worked with the more
> > than dozen EMF-generated metamodels, including when
> > we have models that use a mixture of metamodels.
> > This also works for a model when loaded from an .xsd
> > file (that is, a model that only uses the XSD
> > metamodel), but as soon as I open a model that uses
> > my extended metamodel AND the XSD metamodel, then the
> > ItemProviders don't seem to find the labels or they
> > don't find the icons. (What's even more bizarre is
> > that they icons and labels do show up correctly if
> > the root object is an instance of an XSD metaclass,
> > but if we try to create an instance of an XSD
> > metaclass under one of our own, then there is a
> > probem.) I suspect the problem is in my code, but is
> > there something different about how XSD does it's
> > icons and string localization (i18n) compared to
> > normal EMF metamodels? One of my collegues is trying
> > to generate an Editor for our metamodel to see if our
> > generated providers work correctly that way.
> >
> > Thanks in advance, Randall Hauch
>
--------------F00DC4C90DE349D4E05A4107
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Randall,
<p>Are your overriding delegatedGetImage/delegatedGetString in your XyzEditPlugin?
The item provider adapter factory implements ComposeableAdapterFactory,
so it should be okay. Putting the factories in the right order is
important, I assume your derived version comes first...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Thanks, Ed.</font></font> <font face="Arial"><font size=-1>We
re-implemented ResourceLocator and were delegating the 'getString' and
getIcon' methods (just to name a few) - I thought we were doing that correctly.
I'm wondering whether the XSDEditPlugin doesn't work with the ComposedAdapterFactory.
Do you think creating a new ItemProviderAdapterFactory implementation might
work, or is that part not so different from what EMF is now doing?
Thoughts?</font></font>
<blockquote dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
in message <a href="news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.com</a>...Randall,
<p>If you want an XMI serialization you'll need to pick a resource impl
and add in the stuff that's needed. Your best best is probably to
mixin the XMIResource interface and duplicate the necessary code; many
of the methods could throw exceptions since they won't be used. Another
approach is to serialize into the XSD's DOM by overriding the changeAttribute/changeReference
methods in your derived classes, i.e., you could use non-schema namespace
attributes and/or annotations to serialize your extensions into well-formed
XML Schema DOM...
<p>The XSD item providers were generated a long time before our current
generator support. They haven't been regenerated using that latest
generator. So one of the problems is that the XSDEditPlugin does
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify
the Edit plugin class. If this were properly in place, your
extended model would properly delegate icon/string fetching to the XSDEditPlugin.
We need to address this properly, but that will take significant time since
we have so many things to do and so little time. I'm not sure what
to suggest as an immediate workaround. Copying would certainly work
for the time being. Another approach is to hand code the delegation
to the XSDEditPlugin from your derived XyzEditPlugin...
<br>
<p>Randall Hauch wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I'd
like to reuse the XSD metamodel by extending a few of the constructs (to
add some new attributes), adding some of my own, and then restricting the
use of others. This is very easy to do with other EMF generated metamodels.
However, I'm running into a few issues.</font></font>
<ol>
<li>
<font face="Arial"><font size=-1>Because this is an extension, writing
out to .xsd format is no longer an option. Luckily there's .xmi.
Is there an easy way to read and write to XMI but still use the XSDResourceImpl
(to keep all the benefits of that impl as the Resource)? XSDResourceImpl
doesn't extend XMIResourceImpl or XMLResourceImpl.</font></font></li>
<li>
<font face="Arial"><font size=-1>I'm running into a lot of difficulty with
the item providers and (re)using the resource bundle for the XSD.
I'm using a ComposedAdapterFactory to wrap the ItemProviderAdapterFactory
instances for various metamodels. This approach has worked with the
more than dozen EMF-generated metamodels, including when we have models
that use a mixture of metamodels. This also works for a model when
loaded from an .xsd file (that is, a model that only uses the XSD metamodel),
but as soon as I open a model that uses my extended metamodel AND the XSD
metamodel, then the ItemProviders don't seem to find the labels or they
don't find the icons. (What's even more bizarre is that they icons
and labels do show up correctly if the root object is an instance of an
XSD metaclass, but if we try to create an instance of an XSD metaclass
under one of our own, then there is a probem.) I suspect the problem
is in my code, but is there something different about how XSD does it's
icons and string localization (i18n) compared to normal EMF metamodels?
One of my collegues is trying to generate an Editor for our metamodel to
see if our generated providers work correctly that way.</font></font></li>
</ol>
<font face="Arial"><font size=-1>Thanks in advance,</font></font> <font face="Arial"><font size=-1>Randall
Hauch</font></font></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------F00DC4C90DE349D4E05A4107--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Extending the XSD metamodel [message #578348 is a reply to message #30065] |
Mon, 22 September 2003 13:49 |
Randall Hauch
Messages: 79
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00E7_01C380E6.6645A6E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Actually, I overrode the 'getResourceLocator()' method in the =
XyzEditPlugin to return a new implementation that looks locally and then =
delegates if required. I didn't see the those methods when I was =
implementing our code. Is it better to override the 'delegatedGetImage' =
and 'delegatedGetString' methods?
One problem I ran into was that for a while I was using the =
XSDPlugin.getResourceLocator(), but have changed that to be =
XSDEditPlugin.eINSTANCE.getResourceLocator().
Another thing that was throwing us was that XSD appears to put more =
meaningful information in the command's label. We were use to the =
typical generated code having label's like "Set" or "Create", so we =
ended up looking at the result of the command and having our UI =
providers use those object's item provider to get the label and icon.
The final thing was that the standard XMIResourceImpl functionality of =
reading and writing XMI streams does not seem to be compatible. What we =
tried to do was write out an XSD model as XMI and then back in. =
XMIResourceImpl simply writes out all feature values to the stream =
(except for those that match the default), while reading merely tries to =
call the setter for every value it finds in the XMI. Up until extending =
XSD, we've used so very few unsettable features that we've never seen =
this behavior (despite our automated test framework ;-(
We did some refactoring of our code, and are in the middle of getting =
our regression tests to work again. But we should be a lot closer, =
although I think our refactoring will probably end up with still a =
couple of open issues.
Randall
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675FF4.8653F491@ca.ibm.com...
Randall,=20
Are your overriding delegatedGetImage/delegatedGetString in your =
XyzEditPlugin? The item provider adapter factory implements =
ComposeableAdapterFactory, so it should be okay. Putting the factories =
in the right order is important, I assume your derived version comes =
first...=20
=20
Randall Hauch wrote:=20
Thanks, Ed. We re-implemented ResourceLocator and were delegating =
the 'getString' and getIcon' methods (just to name a few) - I thought we =
were doing that correctly. I'm wondering whether the XSDEditPlugin =
doesn't work with the ComposedAdapterFactory. Do you think creating a =
new ItemProviderAdapterFactory implementation might work, or is that =
part not so different from what EMF is now doing? Thoughts? =20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F675535.7B0AF53@ca.ibm.com...Randall,=20
If you want an XMI serialization you'll need to pick a resource =
impl and add in the stuff that's needed. Your best best is probably to =
mixin the XMIResource interface and duplicate the necessary code; many =
of the methods could throw exceptions since they won't be used. Another =
approach is to serialize into the XSD's DOM by overriding the =
changeAttribute/changeReference methods in your derived classes, i.e., =
you could use non-schema namespace attributes and/or annotations to =
serialize your extensions into well-formed XML Schema DOM...=20
The XSD item providers were generated a long time before our =
current generator support. They haven't been regenerated using that =
latest generator. So one of the problems is that the XSDEditPlugin does =
not use the EMFPlugin pattern and hence the XSD.genmodel doesn't specify =
the Edit plugin class. If this were properly in place, your extended =
model would properly delegate icon/string fetching to the XSDEditPlugin. =
We need to address this properly, but that will take significant time =
since we have so many things to do and so little time. I'm not sure =
what to suggest as an immediate workaround. Copying would certainly =
work for the time being. Another approach is to hand code the =
delegation to the XSDEditPlugin from your derived XyzEditPlugin...=20
=20
Randall Hauch wrote:=20
I'd like to reuse the XSD metamodel by extending a few of the =
constructs (to add some new attributes), adding some of my own, and then =
restricting the use of others. This is very easy to do with other EMF =
generated metamodels. However, I'm running into a few issues.=20
1.. Because this is an extension, writing out to .xsd format =
is no longer an option. Luckily there's .xmi. Is there an easy way to =
read and write to XMI but still use the XSDResourceImpl (to keep all the =
benefits of that impl as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl or XMLResourceImpl.=20
2.. I'm running into a lot of difficulty with the item =
providers and (re)using the resource bundle for the XSD. I'm using a =
ComposedAdapterFactory to wrap the ItemProviderAdapterFactory instances =
for various metamodels. This approach has worked with the more than =
dozen EMF-generated metamodels, including when we have models that use a =
mixture of metamodels. This also works for a model when loaded from an =
..xsd file (that is, a model that only uses the XSD metamodel), but as =
soon as I open a model that uses my extended metamodel AND the XSD =
metamodel, then the ItemProviders don't seem to find the labels or they =
don't find the icons. (What's even more bizarre is that they icons and =
labels do show up correctly if the root object is an instance of an XSD =
metaclass, but if we try to create an instance of an XSD metaclass under =
one of our own, then there is a probem.) I suspect the problem is in my =
code, but is there something different about how XSD does it's icons and =
string localization (i18n) compared to normal EMF metamodels? One of my =
collegues is trying to generate an Editor for our metamodel to see if =
our generated providers work correctly that way.=20
Thanks in advance, Randall Hauch
------=_NextPart_000_00E7_01C380E6.6645A6E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3DArial size=3D2>Actually, I overrode the =
'getResourceLocator()'=20
method in the XyzEditPlugin to return a new implementation that looks =
locally=20
and then delegates if required. I didn't see the those =
methods when I=20
was implementing our code. Is it better to override the=20
'delegatedGetImage' and 'delegatedGetString' methods?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>One problem I ran into was that for a =
while I was=20
using the XSDPlugin.getResourceLocator(), but have changed that to be=20
XSDEditPlugin.eINSTANCE.getResourceLocator().</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another thing that was throwing us was =
that XSD=20
appears to put more meaningful information in the command's label. =
We were=20
use to the typical generated code having label's like "Set" or =
"Create", so=20
we ended up looking at the result of the command and having our UI =
providers use=20
those object's item provider to get the label and icon.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The final thing was that the standard=20
XMIResourceImpl functionality of reading and writing XMI streams does =
not seem=20
to be compatible. What we tried to do was write out an XSD =
model as=20
XMI and then back in. XMIResourceImpl simply writes out =
all=20
feature values to the stream (except for those that match the default), =
while=20
reading merely tries to call the setter for every value it =
finds in=20
the XMI. Up until extending XSD, we've used so very few unsettable =
features that we've never seen this behavior (despite our automated test =
framework ;-(</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We did some refactoring of our code, =
and are in the=20
middle of getting our regression tests to work again. But we =
should be a=20
lot closer, although I think our refactoring will probably end up with =
still a=20
couple of open issues.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Randall</FONT></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675FF4.8653F491@ca.ibm.com">news:3F675FF4.8653F491@ca.ibm.=
com</A>...</DIV>Randall,=20
<P>Are your overriding delegatedGetImage/delegatedGetString in your=20
XyzEditPlugin? The item provider adapter factory implements=20
ComposeableAdapterFactory, so it should be okay. Putting the =
factories=20
in the right order is important, I assume your derived version comes =
first...=20
<BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"> <FONT face=3DArial><FONT =
size=3D-1>Thanks,=20
Ed.</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>We =
re-implemented=20
ResourceLocator and were delegating the 'getString' and getIcon' =
methods=20
(just to name a few) - I thought we were doing that correctly. =
I'm=20
wondering whether the XSDEditPlugin doesn't work with the=20
ComposedAdapterFactory. Do you think creating a new=20
ItemProviderAdapterFactory implementation might work, or is that =
part not so=20
different from what EMF is now doing? =
Thoughts?</FONT></FONT> =20
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed=20
Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F675535.7B0AF53@ca.ibm.com">news:3F675535.7B0AF53@ca.ibm.co=
m</A>...Randall,=20
<P>If you want an XMI serialization you'll need to pick a resource =
impl=20
and add in the stuff that's needed. Your best best is =
probably to=20
mixin the XMIResource interface and duplicate the necessary code; =
many of=20
the methods could throw exceptions since they won't be used. =
Another=20
approach is to serialize into the XSD's DOM by overriding the=20
changeAttribute/changeReference methods in your derived classes, =
i.e., you=20
could use non-schema namespace attributes and/or annotations to =
serialize=20
your extensions into well-formed XML Schema DOM...=20
<P>The XSD item providers were generated a long time before our =
current=20
generator support. They haven't been regenerated using that =
latest=20
generator. So one of the problems is that the XSDEditPlugin =
does not=20
use the EMFPlugin pattern and hence the XSD.genmodel doesn't =
specify the=20
Edit plugin class. If this were properly in place, =
your=20
extended model would properly delegate icon/string fetching to the =
XSDEditPlugin. We need to address this properly, but that =
will take=20
significant time since we have so many things to do and so little=20
time. I'm not sure what to suggest as an immediate =
workaround. =20
Copying would certainly work for the time being. Another =
approach is=20
to hand code the delegation to the XSDEditPlugin from your derived =
XyzEditPlugin... <BR> =20
<P>Randall Hauch wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I'd like to reuse the XSD =
metamodel by=20
extending a few of the constructs (to add some new attributes), =
adding=20
some of my own, and then restricting the use of others. =
This is=20
very easy to do with other EMF generated metamodels. =
However, I'm=20
running into a few issues.</FONT></FONT>=20
<OL>
<LI><FONT face=3DArial><FONT size=3D-1>Because this is an =
extension,=20
writing out to .xsd format is no longer an option. =
Luckily=20
there's .xmi. Is there an easy way to read and write to =
XMI but=20
still use the XSDResourceImpl (to keep all the benefits of =
that impl=20
as the Resource)? XSDResourceImpl doesn't extend =
XMIResourceImpl=20
or XMLResourceImpl.</FONT></FONT>=20
<LI><FONT face=3DArial><FONT size=3D-1>I'm running into a lot =
of=20
difficulty with the item providers and (re)using the resource =
bundle=20
for the XSD. I'm using a ComposedAdapterFactory to wrap =
the=20
ItemProviderAdapterFactory instances for various =
metamodels. =20
This approach has worked with the more than dozen =
EMF-generated=20
metamodels, including when we have models that use a mixture =
of=20
metamodels. This also works for a model when loaded from =
an .xsd=20
file (that is, a model that only uses the XSD metamodel), but =
as soon=20
as I open a model that uses my extended metamodel AND the XSD=20
metamodel, then the ItemProviders don't seem to find the =
labels or=20
they don't find the icons. (What's even more bizarre is =
that=20
they icons and labels do show up correctly if the root object =
is an=20
instance of an XSD metaclass, but if we try to create an =
instance of=20
an XSD metaclass under one of our own, then there is a =
probem.) =20
I suspect the problem is in my code, but is there something =
different=20
about how XSD does it's icons and string localization (i18n) =
compared=20
to normal EMF metamodels? One of my collegues is trying =
to=20
generate an Editor for our metamodel to see if our generated =
providers=20
work correctly that way.</FONT></FONT> </LI></OL><FONT =
face=3DArial><FONT=20
size=3D-1>Thanks in advance,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>Randall=20
Hauch</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BLOCKQUOTE></=
BODY></HTML>
------=_NextPart_000_00E7_01C380E6.6645A6E0--
|
|
|
Goto Forum:
Current Time: Sat Apr 20 01:42:46 GMT 2024
Powered by FUDForum. Page generated in 0.04170 seconds |
] 
Search
Help
Register
Login
Home
