Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implict navigation handling for empty string outcomes #747

Closed
eclipse-faces-bot opened this issue Feb 15, 2010 · 11 comments
Closed

Implict navigation handling for empty string outcomes #747

eclipse-faces-bot opened this issue Feb 15, 2010 · 11 comments

Comments

@eclipse-faces-bot
Copy link

Gang -

One of our unit tests here at Oracle tripped up over a small change in behavior between JSF 1.2 and JSF
2. The unit test contains an action method that returns an empty string, eg:

<h:commandButton action="#

{foo.doSomething}

"/>

public String doSomthing()
{
// Do something here

return "";
}

When running against JSF 1.2, the empty string outcome would result in the test case remaining on the
same page, as there is no navigation case that matches this outcome. In JSF2, implicit navigation kicks
in. In particular, the following statement from section 7.4.2 is applied:

If viewIdToTest does not begin with “/�, take the current viewId and look for the last “/�. If not found,
prepend a “/� and continue. Otherwise remove all characters in viewId after, but not including, “/�, then
append viewIdToTest and let the result be viewIdToTest.

In our case, we have the following values:

  • Current viewId: "region/refresh".
  • viewIdToTest: ""

The resulting view id after applying the above logic is "region/". This ends up being treated as an
implicit view id. In our particular test case, there is no view associated with this view id. Instead of
remaining on the same page, we now attempt to navigate to a view that does not exist.

Our test case made the assumption that returning the empty string from the outcome would result in
the same behavior as returning null. This was true in JSF 1.2, but no longer appears to be true in JSF2.
We have tweaked this unit test to return null so that our tests are now passing, but I wanted to follow
up to find out whether this small difference in behavior between "" and null outcomes is intentional. It
seems to me that these should behave the same. It would be easy enough for us to add a sentence to
the spec that states that empty string outcomes should not be treated as implicit view ids. Does
anyone here know of a reason why we shouldn't spec this?

FWIW, my feeling is that, while returning null is a reasonable workaround, there is no way that our unit
test is not the only code out there that is returning empty action outcomes and expecting to stay on the
same page. I would like to see this behavior preserved not so that we can revert our unit test to its
previous behavior (I am fine with our fix), but because the current behavior may break other users as
they upgrade to JSF2.

Environment

Operating System: All
Platform: Macintosh

Affected Versions

[2.0]

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Reported by aschwart

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Was assigned to javaserverfowner

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
cat1

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
frame

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=698

Include deprecation text on element.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=744

  • integrationWithFacelets.fm

Section 10.3.2. Correct xref to point to section in appendix that
includes the facelet taglib schema.

  • appendixA-metadata.fm

To ease migration for Facelet taglibraries declared using pre-JSF 2.0
versions of Facelets, implementations must support loading facelet
taglibrary files that conform to the pre-JSF 2.0 Facelets DTD. Per DTD
conventions, Facelet taglibrary files declare conformance to this DTD
by including text similar to the following in at the top of their
declaring file.

Use of this DTD is officially deprecated. This DTD is included for
reference in Section 1.2.1 "Deprecated DTD for Facelet Taglibraries
Used by Versions of Facelets Prior to JSF 2.0". It is expected that
proper JSF 2.0 Facelet Taglibraries will declare conformance to the
following schema, rather than the deprecated DTD

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=588

  • jsf-api/doc/standard-html-renderkit-base.xml

insert

around text for h:link and h:button

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=639

  • jsf-ri/conf/share/facelets_jsf_core.tld

change "name" to "type" on description of f:event tag

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=509

  • jsf-ri/conf/share/jstl-core.taglib.xml
  • jsf-ri/conf/share/jstl-core.tld

Declare that the old, incorrect, Facelets decaration of the uri for
the JSTL Core taglib be honored, as well as the new, correct one.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=673

  • jsf-api/doc/standard-html-renderkit-base.xml

Clarify what should happen if the target attribute is not specified.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=642

  • javascriptAPI.fm

table 14.4.1, change responseTxt to responseText

reorder rows in table 14.3

make use case for event listeners be correct.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=635

  • userInterfaceComponentModel.fm

3.5.3, 3.5.6.1: remove references to UInput.encodeEnd(). Not for a
very long time has this method been used to instigate validation.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740

  • requestProcessingLifecycle.fm

  • 2.6.1.3 Tighten spec for the localePrefix, libraryName, and
    resourceVersion segments of the resource identifier

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@edburns said:
These are valid 2.0 Rev a issues

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
rogerk said:
changelog

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
Marked as fixed on Tuesday, June 22nd 2010, 3:02:38 am

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
@manfredriem said:
Closing resolved issue out

@eclipse-faces-bot
Copy link
Author

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-747

@eclipse-faces-bot
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants