| Summary: | [UI] selecting a configuration should not clear facets | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Tom Mutdosch <mutdosch> | ||||
| Component: | wst.common | Assignee: | Konstantin Komissarchik <konstantin> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Konstantin Komissarchik <konstantin> | ||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | dytyniak, jzhang, tjbishop | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.0 RC0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Tom Mutdosch
Interesting suggestion. I wonder if we can pull this off in the UI without making things worse and confusing the user. When a server is selected and default facets are applied, that is one configuration. The user would see "default server x configuration" in the configuration drop down. Then they pick another configuration and we augment the previouse set of facets with the new configuration. What if they pick another? We augment yet again? Maybe we need to treat server default facets specially. What if you could define a configuration in a way that says the configuration extends server default configuration. Of course, we cannot guarantee that the result will work (satisfy constraints of all involved facets), but maybe that's fine in some situations. Would we need to be able to constraint by server and/or server version? What happens if server's default configuration and the extending configuration disagree on the version of the same facet? I kind of like the idea of a configuration some how extending a Default Server Configuration. A configuration would specify all of its required facets as well as SERVER_CONTAINER_CONFIGURATION, whose facets would be filled in based on whatever the selected server specified. Like you mentioned, doing it this way avoids all of the complications of keeping track of different facet augmentations as different configurations are selected. There would still be the possibility of constraint violations, but I think that would generally be rare as the server-based facets are generally exclusive of configuration facets. In the event that there are facet version conflicts, there could be a policy where one "wins" (maybe the configuration provider). So the server facets could be added first, and then any configuration that is selected would add onto those facets (replacing any duplicate facets with its own version if it differs). hi can I request that this be handled with a higher priority? Our customers have complained that when selecting a configuration bumps out server default facets, it forces them to have to pick them manually in the facet selection page, which kind of partially defeats the purpose of the configuration setting (so one can pick one and click finish on the 1st page). In addition, I think in most cases the server default facets represent extended capabilities, some of which are essential to make things run (such as J2EE resource binding values in case of WebSphere and BEA). Therefore you almost would never want to de-select the default facets. I will see what I can do to support this scenario for RC0. This feature has been implemented and released into the 2.0 RC0 code stream. Here is the example from the extension point documentation illustrating its use. Note that the extension point is new, defining presets in the facets extension point is now deprecated. I will also attach the snippet from the "What's new in 2.0?" doc (part of WTP ISV documentation). Let me know if there are any issues using the new facility.
<extension point="org.eclipse.wst.common.project.facet.core.presets">
<!-- Defines a dynamic preset which will be synthesized by the provided factory. This particular preset
is actually supplied by the Faceted Project Framework. What it resolves to depends on the context.
If project does not target a runtime, it will contain only the fixed facets with their default
versions. If project targets one or more runtime, this preset will contain facets that are specified
to be the default for the primary runtime. -->
<preset id="default.configuration">
<factory class="org.eclipse.wst.common.project.facet.core.internal.DefaultConfigurationPresetFactory"/>
</preset>
<!-- Creates a preset which extends the "default.configuration" preset and adds two facets. -->
<preset id="my.favorite.preset" extends="default.configuration">
<label>My Favorite Configuration</label>
<description>Here is the description of my favorite configuration.</description>
<facet id="facet_a" version="1.2"/>
<facet id="facet_b" version="2.0"/>
</preset>
</extension>
To clarify, you don't need to define the "default.configuration" preset. That's taken care of by the framework. You just need to worry about the second part:
<extension point="org.eclipse.wst.common.project.facet.core.presets">
<!-- Creates a preset which extends the "default.configuration" preset and
adds two facets. -->
<preset id="my.favorite.preset" extends="default.configuration">
<label>My Favorite Configuration</label>
<description>Here is the description of my favorite
configuration.</description>
<facet id="facet_a" version="1.2"/>
<facet id="facet_b" version="2.0"/>
</preset>
</extension>
Created attachment 64952 [details]
Snippet from the What's New document
FYI - I created 185573 for a backport to 1.5.5 |