Home » Archived » 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  |
 Randall Hauch
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> </DIV>
<DIV><FONT face=3DArial size=3D2>The newer EMF versions generate =
ItemProvider=20
implementations in a way that makes it very easy to override and extend =
how the=20
various PropertyDescriptor objects are created. The basic approach =
is that=20
there is an "add<featureName>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<featureName>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<featureName>PropertyDescriptor(Object)" methods.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>However, few of the ItemProvider =
implementations=20
are written this way. 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> </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. However, it's just not very =
straightforward.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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  |
Eclipse User |
|
|
|
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>
<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> <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. 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</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<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<featureName>PropertyDescriptor(Object)" methods.</font></font> <font face="Arial"><font size=-1>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.</font></font> <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. However, it's just
not very straightforward.</font></font> <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 |
Ed Merks
Messages: 33141
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>
<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> <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. 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</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<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<featureName>PropertyDescriptor(Object)" methods.</font></font> <font face="Arial"><font size=-1>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.</font></font> <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. However, it's just
not very straightforward.</font></font> <font face="Arial"><font size=-1>Randall</font></font></blockquote>
</body>
</html>
--------------8C03FB072BB74D402978BE0D--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:59:59 GMT 2024
Powered by FUDForum. Page generated in 0.03528 seconds |
] 
Search
Help
Register
Login
Home
