Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

WTP Facets UIWG Walkthrough

WTP Facets UI Walkthrough Eclipse UI Best Practices Working Group 7/9/2008

Prep/Homework

Take a look at some screenshots regarding the WTP Facets Framework.

Discussion Topics

Facet configuration in project creation wizards
Runtime targeting

Discussion Notes from Walkthrough

The first wizard page of the Project Creation wizards looks OK and complies with the Eclipse UI guildelines. The idea for choosing the version of the primary facet on the first wizard page is accepted well.
Eugene: I haven't heard from UI Expert group about this, but I think this page is overusing groups for single elements. If there is just one element in the group you should be using just plain label and not a group. Then UI would look less crowded. Also, ordering of fields is somewhat odd. It seems like the primary control there is the EJB facet version (btw, should it be called "EJB specification version" or something like that?), and then if this EJB should be added to EAR or not. Then, perhaps, "Target runtime". And then configuration (is it EJB faced configuration or configuration for the target runtime? also unclear from the UI).
When looking at the Project Facets dialog and the Project Facets property page there are lot of recommendations suggested.
  • the checkbox in front of each facet
    • the current situation is that if the facet cannot be uninstalled, the checkbox cannot be unchecked. Instead a tooltip pops up explaining why it cannot be unchecked. This tooltip is quite a strange idea and does not comply with the Eclipse UI guidelines
    • checkboxes that should not be unchecked should be grayed
    • even better all checkboxes should be allowed to be unchecked, but if the user unchecks a facet that cannot be uninstall, then an validation error should appear.
  • locking/unlocking
    • locking of facets is very weird and it seems that nobody (except Konstantin) knows what exactly it does. It seems like it filters facets depending on their constraints.
    • if it is about filtering of facets, it would be much clearer for the user if there is a global checkbox for showing/hiding the appropriate facets for the current use case.
Eugene: It been suggested to investigate if lock/unlock can be replaced with "show all" or "show only valid/available facets"
  • validation
    • the idea of showing validation errors is very much liked
    • validation error entries should not be selectable. Currently, they are and it this implies that the user can do something with this error (like quick fix), but actually he has no options for actions.
    • validation errors should not appear in the special widget below the facets list view, but in the dialog box title, or the property page title. This is according to the Eclipse UI guidelines.
Eugene: You can also try to show error decoration on conflicting invalid entries and then show more detailed error on the details tab.
  • Configurations drop-down
    • The Save button should have ellipsis :-)
    • It would be better that the Save/Delete buttons are replaced with Edit/Remove/New/Import buttons like in the Java > Code Style > Formatter preferences page.
    • Save/Delete seems to be rarely used, even never by the ordinary users. So, it is better to remove them at all.
    • Creating and Deleting of facet configurations should be moved in a Preferences page. A link ("Configure") to this preferences page could replace the Save/Delete buttons.
Eugene: Boris pointed out that it is confusing to have Save and Delete buttons next to "Configurations" drop down (should it be called "Templates"?) and compared this UI with project prefs / Java Code Style / Formatter, which uses "Edit.../Remove" approach (though personally I think it is not the same as facet UI)
  • Runtime view
    • again validation errors are better than filtering. The user should see all available runtimes, otherwise it may be frustrating why a certain runtime is not available. When selecting invalid runtime, a validation error should appear.
Eugene: Mik and Boris pointed out that it is hard to figure out why certain selections are removed (e.g. removing versions of war facet only when particular tomcat runtime is selected). It been said that in this case it is better to allow user select an invalid combination and show him a error that selected combination is conflicting or invalid. From myself I also would like to add that it is somewhat confusing to have two somewhat parallel concepts - facets and runtimes. They can be selected independently, but then they also related to each other. Why runtimes aren't facets?

Conclusions/To-do's

Send notes to Konstantin Komissarchik (Kaloyan)
Follow up walkthrough

Other thoughts

Eugene:
I also would like to bring up another somewhat confusing issue about facets. It is that for Java projects (and probably for some other projects) they imply certain jars to be added as project dependencies/classpath. I am not completely sure about internals of this, but this feature is conflicting with dependency management mechanisms and tools, such as Maven and also somewhat overlaps with JDT's own build path configuration UI. It would be interesting to see more detailed discussion on that.
Not sure if you know, but m2e Maven tools project is being provisioned at Eclipse and it is based on m2eclipse, which already has some WTP support (screenshots are based on WTP 2.x, so it may look slightly different then one shown to the UI expert group).
I would really like to find a good way to interoperate between Maven tools and WTP facets and how UI for that should look like. There is some interesting challenges around configuring Maven projects to work with WTP, but that perhaps belong to the cross project issues mailing list.

Back to the top