|
| Re: What's broken in natures? [message #2239 is a reply to message #2207] |
Fri, 24 October 2008 22:35   |
 Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
Good question!
Natures are extremely simple. The original use case for natures is to
basically serve as a flag modeling something akin to a project type. The
good UI that you speak of for adding and removing natures would need a lot
more information and callable behaviors than is provided by the natures
API. The limitations make sense since the natures API was written with
simple use cases in mind and natures were not intended to be
fully-described and self-supporting.
Let's look at one API as an example. The IProjectNature interface has
configure() and deconfigure() methods that nature authors get to
implement. These methods get called when a nature is added to or removed
from a project. Notice how those methods take no parameters. That means it
is not possible to pass in a configuration object that would let the user
have input as these actions take place. So what, you say. We've solved
that problem before. We will just create IProjectNature2 with variants of
those two methods capable of taking parameters. Problem solved. Not quite.
The issue is that there are many natures already implemented in various
Eclipse projects and commercial products. For years nature authors have
been working around this API limitation. The most common work-around is to
move most of the interesting code outside these two methods. In the case
of the configure() method all of this code is embedded in various project
creation wizards and "Enable function X" menu actions. The configure()
implementations themselves typically are not sufficient to properly
configure the project and often rely on stuff happening prior to the
nature getting added. For the most part, the deconfigure() methods are
implemented as no-ops. Since there is no UI for the user to remove a
nature, why bother with implementing this method?
In short, the biggest obstacle to making it possible for users to add and
remove natures are the existing nature implementations. Practically every
nature out there would be broken behaviorally if UI for adding and
removing natures was introduced.
Ok. So we need a more gradual phased-in approach that doesn't give
everyone in the Eclipse Community a massive coronary. Enter facets. We
started from scratch and designed the facets API together with UI for
adding and removing them. The framework evolved over the years to cover a
lot of different use cases that adopters brought to the table. Since
making a project faceted is controlled by a flag (a nature, actually), the
project wizard owner get to opt-in when they are ready. Part of the opt-in
process is gathering all of the code that strewn about in various wizards
and actions and writing a facet based on that code. It often make sense to
retain any existing natures for backwards compatibility, but facets would
now control adding and removing them.
The pattern of wrapping a facet around a nature is particularly important
when you consider the case of an Eclipse Project re-using another
Project's functionality. We need a solution for enabling a downstream
Project to transition to facets while the upstream Project is not ready
yet and continues using natures. The original example of this is WTP's
re-use of JDT's java nature for various WTP projects like Dynamic Web
Project. It was necessary for WTP to move forward with creating faceted
projects without depending on JDT adopting the same approach and making
requisite changes to it's code base. The facets architecture allowed us in
WTP to implement a java facet on our own that wraps JDT's java nature.
JDT's Java Project (as well as all the other projects that re-use java
nature) continue to work as before while WTP users start benefiting from
the richer experience provided by facets. If JDT ever decided to adopt
facets, the implementation of the java facet can move to JDT. For now, it
will live in the JDT Enablement component of this Project.
In short, the approach taken is to enable gradual and controlled adoption
without asking everyone in the community to jump at the same time. :)
I hope this answered your question.
- Konstantin
|
|
|
|
|
|
|
| Re: What's broken in natures? [message #571354 is a reply to message #2207] |
Fri, 24 October 2008 22:35 |
Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
Good question!
Natures are extremely simple. The original use case for natures is to
basically serve as a flag modeling something akin to a project type. The
good UI that you speak of for adding and removing natures would need a lot
more information and callable behaviors than is provided by the natures
API. The limitations make sense since the natures API was written with
simple use cases in mind and natures were not intended to be
fully-described and self-supporting.
Let's look at one API as an example. The IProjectNature interface has
configure() and deconfigure() methods that nature authors get to
implement. These methods get called when a nature is added to or removed
from a project. Notice how those methods take no parameters. That means it
is not possible to pass in a configuration object that would let the user
have input as these actions take place. So what, you say. We've solved
that problem before. We will just create IProjectNature2 with variants of
those two methods capable of taking parameters. Problem solved. Not quite.
The issue is that there are many natures already implemented in various
Eclipse projects and commercial products. For years nature authors have
been working around this API limitation. The most common work-around is to
move most of the interesting code outside these two methods. In the case
of the configure() method all of this code is embedded in various project
creation wizards and "Enable function X" menu actions. The configure()
implementations themselves typically are not sufficient to properly
configure the project and often rely on stuff happening prior to the
nature getting added. For the most part, the deconfigure() methods are
implemented as no-ops. Since there is no UI for the user to remove a
nature, why bother with implementing this method?
In short, the biggest obstacle to making it possible for users to add and
remove natures are the existing nature implementations. Practically every
nature out there would be broken behaviorally if UI for adding and
removing natures was introduced.
Ok. So we need a more gradual phased-in approach that doesn't give
everyone in the Eclipse Community a massive coronary. Enter facets. We
started from scratch and designed the facets API together with UI for
adding and removing them. The framework evolved over the years to cover a
lot of different use cases that adopters brought to the table. Since
making a project faceted is controlled by a flag (a nature, actually), the
project wizard owner get to opt-in when they are ready. Part of the opt-in
process is gathering all of the code that strewn about in various wizards
and actions and writing a facet based on that code. It often make sense to
retain any existing natures for backwards compatibility, but facets would
now control adding and removing them.
The pattern of wrapping a facet around a nature is particularly important
when you consider the case of an Eclipse Project re-using another
Project's functionality. We need a solution for enabling a downstream
Project to transition to facets while the upstream Project is not ready
yet and continues using natures. The original example of this is WTP's
re-use of JDT's java nature for various WTP projects like Dynamic Web
Project. It was necessary for WTP to move forward with creating faceted
projects without depending on JDT adopting the same approach and making
requisite changes to it's code base. The facets architecture allowed us in
WTP to implement a java facet on our own that wraps JDT's java nature.
JDT's Java Project (as well as all the other projects that re-use java
nature) continue to work as before while WTP users start benefiting from
the richer experience provided by facets. If JDT ever decided to adopt
facets, the implementation of the java facet can move to JDT. For now, it
will live in the JDT Enablement component of this Project.
In short, the approach taken is to enable gradual and controlled adoption
without asking everyone in the community to jump at the same time. :)
I hope this answered your question.
- Konstantin
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02637 seconds
] 
Search
Help
Register
Login
Home
