Description Scott Paxton 2008-11-12 15:07:11 EST

This is a new feature request to separate out some comments I made to Bug 251934.  In light of the new Library Provider framework, which allows much more direct control for setting up a project, I'd like to recommend removing the remaining input fields on the facet-install page.  At best they seem to be showing defaults that would rarely or never be changed by a user, and at worst the values actually contradict what a library provider may do to the project config.

These UI fields are:

JSF Configuration File
JSF Servlet Name
JSF Servlet Classname
URL Mapping Patterns


One use case I'm thinking about here is installing the JSF facet into a project that targets a portal server.  In the portal case there is actually no FacesServlet, but instead a Faces Portlet that gets defined elsewhere (not in web.xml).  In my current implementation I have an additional facet that "fixes up" the configuration that the JSF facet already performed, by removing the servlet declaration and mappings from web.xml and doing whatever other portal-specific setup that's required.  I'd like to move that logic into a library provider and not require the weight of an extra facet, which consolidates the project setup steps nicely.  But in any case the JSF facet page is showing the values for the JSF servlet info which will not end up in a portal project in the end.  I have no problem with the JSF facet installer doing setup with these default values (i.e. I'd still remove the FacetServlet myself), but I don't think they should be shown in the UI here.

Similarly, our adopter product prefers the standard "*.faces" servlet mapping, which is not given as a URL Mapping Pattern by default.  We always add that as an additional mapping after-the-fact (again, this would ideally be incorporated into a library provider going forward).  Once again the UI is therefore inconsistent with the results.  

So I'd like see these fields removed from the facet install page.  I personally think they are such obvious defaults that they shouldn't need to be changed by most end-users anyway (though I did find Bug 154573 which might be relevant).  But even if they are necessary to keep around in a user-editable way, moving them into product preferences may make more sense.  Preferences has the advantages of:  a) the values shouldn't need to change on a project-by-project basis so it de-clutters the facet page, and b) an adopter product can more easily change default values in prefs by using a product plugin (ex. overriding the FacesServlet classname as in 154573, or adding the *.faces URL mapping as in my scenario).