Re: [jbosside-dev] Extension Point best Practices
Just updating this thread so i matches my understanding of extension
points ;)
paulweb515 had 3 suggestions:
<paulweb515> rawblem: I've seen 3 common usages
<paulweb515> rawblem: 1) Tell you users to implement IPackageType that
has
setId(*) as well as getId(*) ... then you can set your user's data when
you
create the executable extension
If you just let the extender implement IChef, he'll be filling in id and
label twice, once in the extension point, and once in API.
So paulweb suggests setters, but that's not a great idea because then
anyone
who gets a reference to your object can
change the ID and label. Obviously that's a glaring error.
There should be no setters in the required interface if you don't need to
change it.
<paulweb515> rawblem: 2) Like ViewPart, create an abstract base
class
that
they must use instead of just an interface. ViewPart uses
setInitializationData(*) to store the config element for the client to
use
in a protected method, and extracts id, label etc into the base abstract
class ... but they're private, and it only provides public final String
getId() so they can't change it
This sounds like the best way, I'll look at it momentarily.
This is the most flexible setup. Note that the setInitializationData is
actually from IExtensionExecutable and it is a way for user classes to
*optionally* be told what is actually inside the plugin definition.
Thus the IViewPart has the getId() but the user could just implement
that by hardcode a value in the getter....AbstractViewPart then ensures
via IExtensionExecutable to setup the IViewPart contract to return the
correct value.
<paulweb515> or 3) don't store the ID in the object, have
that ID be
part of
an association that your extension point knows.
Not exactly the best way, because then given an IChef, you cannot get
his id
or label.
Makes perfect sense if the id value is something not needed all the time;
e.g.
fastViewWidthRatio for a ViewPart.
All are welcome to give forth their suggestions or other best
practices
they
use WRT extension points ;)
I'll probably be using a methodology similar to the one paulweb515
suggested.
Having an interface and require users to extend a concrete abstract class
instead
is a design flaw because then the interface is just dead code.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com