JavaServer Faces (JSF) Converters and Navigation

The claimed answer is A. JSF (JavaServer Faces) is primarily a presentation technology for building user interfaces in Java web applications. It is not a business rules specification technology (Option B) or a persistence technology (Option C). JSF handles the presentation layer through UI components and managed beans.

The claimed answers are A and D. This navigation rule is technically valid XML (A is true), but it's incomplete because a navigation case should have a tag to specify when this navigation should occur (D is true). Option B is incorrect because it won't throw RuntimeException - it's syntactically valid. Option C is incorrect because page.jsp could be displayed as a default view or through other means.

In JSF, if <from-view-id> is omitted from a navigation rule, it defaults to wildcard matching (*), applying to all views. Therefore, both configurations define a global navigation rule that redirects to /page.jsp whenever the outcome is 'outcome', making them identical in effect.

The outcome returned by the link is 'hugo', which does not match any of the defined <from-outcome> cases ('Hello' or 'Turtle') in the navigation rule. In JSF, if no navigation case matches the returned outcome, the navigation handler keeps the user on the current page.

The claimed answer is False (B). JSF navigation rules using do not support EL expressions in the view path. Navigation rules are static configuration defined in faces-config.xml, and EL expressions like #{myBean.id} cannot be used directly in the tag. Dynamic navigation with parameters would be handled differently in the action method or through other mechanisms.

The claimed answer is C. When a commandLink or commandButton action method returns null, JSF executes the action method but then re-renders the current view instead of navigating to a different page. Option A and B are incorrect because no exception is thrown. Option D is misleading - it's not just 'same page', it's explicitly re-rendering the current view after action execution.

In JSF (JavaServer Faces) navigation rules, specifying <from-action> and <to-view-id> without a <from-outcome> is perfectly legal. When <from-outcome> is omitted, any outcome returned by the specified action method will match the rule and trigger the navigation.

The claimed answer is True. In JSF, if no navigation rule matches a given action outcome, the framework's default behavior is to redisplay the current page. This is a fallback mechanism that ensures the application doesn't fail when navigation rules are incomplete.

The JSF navigation-rule element only accepts specific nested elements: from-view-id, navigation-case, and redirect. The name, icon, view, description, and case elements shown in options are NOT part of the navigation-rule schema. Options A (name), C (view), and E (case) correctly identify invalid elements.

This is a valid JSF navigation rule declaration. It correctly defines a from-view-id of /main.jsp, contains two properly structured navigation-case elements with from-action, from-outcome, and to-view-id, and follows the required XML nesting structure for faces-config.xml.

When a converter throws an exception during value conversion, JSF marks the component as invalid. The isValid() method of the UIComponent (or the field's validator) returns false because the conversion failure sets the valid flag to false, preventing further processing.

JSF provides built-in standard error messages for conversion and validation failures. These messages are automatically displayed in h:messages or h:message tags when conversion or validation errors occur, though they can be customized via message bundles.

Both approaches are equivalent. h:outputFormat is a convenience tag that internally uses f:convertDateTime for date formatting. Wrapping f:convertDateTime inside h:outputText achieves the same result, as the converter applies to the outputText value.

The convertDateTime converter's dateStyle property accepts four predefined values: short, medium, long, and full. These correspond to java.text.DateFormat style constants and determine the verbosity of the date display format. All four options shown are valid.

JSF allows multiple validators to be attached to a single component. You can nest multiple f:validator tags or use the validatorIds attribute with Validator interface implementations. All validators execute in sequence during the Process Validations phase.

Only ONE converter can be attached to a component. Converters are mutually exclusive - applying a second converter replaces the first. This is because a component can only have one single converted value; multiple converters would create ambiguity about which conversion logic to apply.