|Re: Facet install delegate child facet mechanism [message #203244 is a reply to message #203188]
||Sat, 27 October 2007 20:01
| Cameron Bateman
Registered: July 2009
Thanks Konstantin, that makes sense. From a UI perspective though there |
is a case where it still may be convenient. An example is the
servlet-mappings. The JSF facet installation UI collects servlet-mapping
url patterns from the user to initialize the web.xml for the Faces
servlet. But if we have a dependent facet that we know will override
these with separate UI in the next page of the new project wizard, this is
confusing to the user. Ideally, if we know a piece of install data will
be overridden, we would hide the UI.
Perhaps there is room for mechanism in the installation data model that
allows facets to say "I will be setting property
'org.eclipse.jst.jsf.SERVLET_MAPPINGS'" which be constructed in such a way
that overrides could be detected and a parent facet could ask "if not
'o.e.j.jsf.S' overridden, then show my UI".
Since the overriden data is overriden hierarchically (dependent facets
override parents in a tree structure), the "install A and B, B->A" case
would still behave the same as "install A and some time later B, B->A".
Konstantin Komissarchik wrote:
> I would recommend making the web.xml change that makes sense for the
> JSF-only case in the JSF install delegate. A facet that depends on JSF
> would then override the change in it's own install delegate. This might
> seem less-than-optimal, but this way it is much easier to make sure that
> the right thing happens in all cases. For instance, the "facets A and B
> installed at the same time" case should ideally behave identically to
> the "facet A is installed first, then facet B is installed some time
> later". This approach also makes it easier to figure out what should
> happen on uninstall.
> Hope this helps.
> - Konstantin
|Re: Facet install delegate child facet mechanism [message #203259 is a reply to message #203244]
||Sat, 27 October 2007 23:29
Originally posted by: kosta.bea.com|
If you are only trying to get a solution to optimize the UI, you can
achieve that with the current API. Basically, add a property to JSF
facet's action config that controls whether a particular option should
still be available. The dependent facet (rather than JSF facet) can look
through the wizard context to see if the JSF facet install action is
present. If it is, it can set this property which would disable/hide the
UI on the JSF facet's page.
Does this help?
Powered by FUDForum
. Page generated in 0.01775 seconds