Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » XSD ItemProviders should use EMF pattern for creating PropertyDescriptors
XSD ItemProviders should use EMF pattern for creating PropertyDescriptors [message #32663] Wed, 05 November 2003 01:07 Go to next message
Randall Hauch is currently offline Randall HauchFriend
Messages: 79
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C3A306.DA8BC470
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a suggestion for future versions of the XSD plugins, which were =
originally built with an earlier version of EMF (or its predecessor?).

The newer EMF versions generate ItemProvider implementations in a way =
that makes it very easy to override and extend how the various =
PropertyDescriptor objects are created. The basic approach is that =
there is an "add<featureName>PropertyDescriptor(Object)" method for each =
structural feature defined by the EClass to which the ItemProvider =
corresponds, and the "getPropertyDescriptors(Object)" method simply
a.. calls super.getPropertyDescriptors(obj)
b.. calls each of the "add<featureName>PropertyDescriptor(Object)" =
methods
This is great when just a few of the PropertyDescriptors are to be =
created using different parameters, since you only have to override the =
appropriate "add<featureName>PropertyDescriptor(Object)" methods.

However, few of the ItemProvider implementations are written this way. =
For example, the "getPropertyDescriptors(Object)" method on =
XSDSimpleTypeDefinitionItemProvider actually creates all of the =
PropertyDescriptors in-line, so it's not straightforward to override =
just a few of them.

This is not high-priorty, though, since it is possible in an =
ItemProvider subclass to remove one or more PropertyDescriptors created =
in the superclass implementations and add new forms that better suit =
your need. However, it's just not very straightforward.

Randall
------=_NextPart_000_0010_01C3A306.DA8BC470
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.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This is a suggestion for future =
versions of the XSD=20
plugins, which were originally built with an earlier version of EMF (or =
its=20
predecessor?).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The newer EMF versions&nbsp;generate =
ItemProvider=20
implementations in a way that makes it very easy to override and extend =
how the=20
various PropertyDescriptor objects are created.&nbsp; The basic approach =
is that=20
there is an "add&lt;featureName&gt;PropertyDescriptor(Object)" method =
for each=20
structural feature defined by the EClass to which the ItemProvider =
corresponds,=20
and the "getPropertyDescriptors(Object)" method simply</FONT></DIV>
<UL>
<LI><FONT face=3DArial size=3D2>calls=20
super.getPropertyDescriptors(obj)</FONT></LI>
<LI><FONT face=3DArial size=3D2>calls each of the=20
"add&lt;featureName&gt;PropertyDescriptor(Object)" =
methods</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>This is great when just a few of the=20
PropertyDescriptors are to be created using different parameters, since =
you only=20
have to override the appropriate=20
"add&lt;featureName&gt;PropertyDescriptor(Object)" methods.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>However, few of the ItemProvider =
implementations=20
are written this way.&nbsp; For example, the =
"getPropertyDescriptors(Object)"=20
method on XSDSimpleTypeDefinitionItemProvider actually creates all of =
the=20
PropertyDescriptors in-line, so it's not straightforward to override =
just a few=20
of them.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This is not high-priorty, though, since =
it is=20
possible in an ItemProvider subclass to remove one or more =
PropertyDescriptors=20
created in the superclass implementations and add new forms that better =
suit=20
your need.&nbsp; However, it's just not very =
straightforward.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Randall</FONT></DIV></BODY></HTML>

------=_NextPart_000_0010_01C3A306.DA8BC470--
Re: XSD ItemProviders should use EMF pattern for creating PropertyDescriptors [message #32700 is a reply to message #32663] Wed, 05 November 2003 12:41 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

--------------8C03FB072BB74D402978BE0D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Randall,

Yes, the newer patterns are much more convenient and we should migrate
xsd.edit to use them consistently.


Randall Hauch wrote:

> This is a suggestion for future versions of the XSD plugins, which
> were originally built with an earlier version of EMF (or its
> predecessor?). The newer EMF versions generate ItemProvider
> implementations in a way that makes it very easy to override and
> extend how the various PropertyDescriptor objects are created. The
> basic approach is that there is an
> "add<featureName>PropertyDescriptor(Object)" method for each
> structural feature defined by the EClass to which the ItemProvider
> corresponds, and the "getPropertyDescriptors(Object)" method simply
>
> * calls super.getPropertyDescriptors(obj)
> * calls each of the "add<featureName>PropertyDescriptor(Object)"
> methods
>
> This is great when just a few of the PropertyDescriptors are to be
> created using different parameters, since you only have to override
> the appropriate "add<featureName>PropertyDescriptor(Object)"
> methods. However, few of the ItemProvider implementations are written
> this way. For example, the "getPropertyDescriptors(Object)" method on
> XSDSimpleTypeDefinitionItemProvider actually creates all of the
> PropertyDescriptors in-line, so it's not straightforward to override
> just a few of them. This is not high-priorty, though, since it is
> possible in an ItemProvider subclass to remove one or more
> PropertyDescriptors created in the superclass implementations and add
> new forms that better suit your need. However, it's just not very
> straightforward. Randall

--------------8C03FB072BB74D402978BE0D
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>Yes, the newer patterns are much more convenient and we should migrate
xsd.edit to use them consistently.
<br>&nbsp;
<p>Randall Hauch wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>This
is a suggestion for future versions of the XSD plugins, which were originally
built with an earlier version of EMF (or its predecessor?).</font></font>&nbsp;<font face="Arial"><font size=-1>The
newer EMF versions generate ItemProvider implementations in a way that
makes it very easy to override and extend how the various PropertyDescriptor
objects are created.&nbsp; The basic approach is that there is an "add&lt;featureName>PropertyDescriptor(Object)"
method for each structural feature defined by the EClass to which the ItemProvider
corresponds, and the "getPropertyDescriptors(Object)" method simply</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>calls super.getPropertyDescriptors(obj)</font></font></li>

<li>
<font face="Arial"><font size=-1>calls each of the "add&lt;featureName>PropertyDescriptor(Object)"
methods</font></font></li>
</ul>
<font face="Arial"><font size=-1>This is great when just a few of the PropertyDescriptors
are to be created using different parameters, since you only have to override
the appropriate "add&lt;featureName>PropertyDescriptor(Object)" methods.</font></font>&nbsp;<font face="Arial"><font size=-1>However,
few of the ItemProvider implementations are written this way.&nbsp; For
example, the "getPropertyDescriptors(Object)" method on XSDSimpleTypeDefinitionItemProvider
actually creates all of the PropertyDescriptors in-line, so it's not straightforward
to override just a few of them.</font></font>&nbsp;<font face="Arial"><font size=-1>This
is not high-priorty, though, since it is possible in an ItemProvider subclass
to remove one or more PropertyDescriptors created in the superclass implementations
and add new forms that better suit your need.&nbsp; However, it's just
not very straightforward.</font></font>&nbsp;<font face="Arial"><font size=-1>Randall</font></font></blockquote>

</body>
</html>

--------------8C03FB072BB74D402978BE0D--
Re: XSD ItemProviders should use EMF pattern for creating PropertyDescriptors [message #580441 is a reply to message #32663] Wed, 05 November 2003 12:41 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31346
Registered: July 2009
Senior Member
--------------8C03FB072BB74D402978BE0D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Randall,

Yes, the newer patterns are much more convenient and we should migrate
xsd.edit to use them consistently.


Randall Hauch wrote:

> This is a suggestion for future versions of the XSD plugins, which
> were originally built with an earlier version of EMF (or its
> predecessor?). The newer EMF versions generate ItemProvider
> implementations in a way that makes it very easy to override and
> extend how the various PropertyDescriptor objects are created. The
> basic approach is that there is an
> "add<featureName>PropertyDescriptor(Object)" method for each
> structural feature defined by the EClass to which the ItemProvider
> corresponds, and the "getPropertyDescriptors(Object)" method simply
>
> * calls super.getPropertyDescriptors(obj)
> * calls each of the "add<featureName>PropertyDescriptor(Object)"
> methods
>
> This is great when just a few of the PropertyDescriptors are to be
> created using different parameters, since you only have to override
> the appropriate "add<featureName>PropertyDescriptor(Object)"
> methods. However, few of the ItemProvider implementations are written
> this way. For example, the "getPropertyDescriptors(Object)" method on
> XSDSimpleTypeDefinitionItemProvider actually creates all of the
> PropertyDescriptors in-line, so it's not straightforward to override
> just a few of them. This is not high-priorty, though, since it is
> possible in an ItemProvider subclass to remove one or more
> PropertyDescriptors created in the superclass implementations and add
> new forms that better suit your need. However, it's just not very
> straightforward. Randall

--------------8C03FB072BB74D402978BE0D
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>Yes, the newer patterns are much more convenient and we should migrate
xsd.edit to use them consistently.
<br>&nbsp;
<p>Randall Hauch wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>This
is a suggestion for future versions of the XSD plugins, which were originally
built with an earlier version of EMF (or its predecessor?).</font></font>&nbsp;<font face="Arial"><font size=-1>The
newer EMF versions generate ItemProvider implementations in a way that
makes it very easy to override and extend how the various PropertyDescriptor
objects are created.&nbsp; The basic approach is that there is an "add&lt;featureName>PropertyDescriptor(Object)"
method for each structural feature defined by the EClass to which the ItemProvider
corresponds, and the "getPropertyDescriptors(Object)" method simply</font></font>
<ul>
<li>
<font face="Arial"><font size=-1>calls super.getPropertyDescriptors(obj)</font></font></li>

<li>
<font face="Arial"><font size=-1>calls each of the "add&lt;featureName>PropertyDescriptor(Object)"
methods</font></font></li>
</ul>
<font face="Arial"><font size=-1>This is great when just a few of the PropertyDescriptors
are to be created using different parameters, since you only have to override
the appropriate "add&lt;featureName>PropertyDescriptor(Object)" methods.</font></font>&nbsp;<font face="Arial"><font size=-1>However,
few of the ItemProvider implementations are written this way.&nbsp; For
example, the "getPropertyDescriptors(Object)" method on XSDSimpleTypeDefinitionItemProvider
actually creates all of the PropertyDescriptors in-line, so it's not straightforward
to override just a few of them.</font></font>&nbsp;<font face="Arial"><font size=-1>This
is not high-priorty, though, since it is possible in an ItemProvider subclass
to remove one or more PropertyDescriptors created in the superclass implementations
and add new forms that better suit your need.&nbsp; However, it's just
not very straightforward.</font></font>&nbsp;<font face="Arial"><font size=-1>Randall</font></font></blockquote>

</body>
</html>

--------------8C03FB072BB74D402978BE0D--


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:XSD ItemProviders should use EMF pattern for creating PropertyDescriptors
Next Topic:XMI, Rose, and EML
Goto Forum:
  


Current Time: Tue Aug 04 18:15:05 GMT 2020

Powered by FUDForum. Page generated in 0.01263 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top