You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@deltaspike.apache.org by bu...@apache.org on 2014/11/26 21:22:02 UTC
svn commit: r930651 [7/10] - in /websites/staging/deltaspike/trunk/content:
./ staging/documentation/
Added: websites/staging/deltaspike/trunk/content/staging/documentation/jsf.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/staging/documentation/jsf.html (added)
+++ websites/staging/deltaspike/trunk/content/staging/documentation/jsf.html Wed Nov 26 20:22:01 2014
@@ -0,0 +1,2630 @@
+<!DOCTYPE html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<meta name="description" content="deltaspike-generate-pages">
+<meta name="author" content="chm">
+
+<title>JSF</title>
+
+<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->
+
+<!-- Styles -->
+
+<link href="https://deltaspike.apache.org/resources/css/bootstrap.css" rel="stylesheet">
+<link href="https://deltaspike.apache.org/resources/css/bootstrap-responsive.css" rel="stylesheet">
+
+<style type="text/css">
+/* Stylesheet for CodeRay to match GitHub theme | MIT License | http://foundation.zurb.com */
+/*pre.CodeRay {background-color:#f7f7f8;}*/
+.CodeRay .line-numbers{border-right:1px solid #d8d8d8;padding:0 0.5em 0 .25em}
+.CodeRay span.line-numbers{display:inline-block;margin-right:.5em;color:rgba(0,0,0,.3)}
+.CodeRay .line-numbers strong{font-weight: normal}
+table.CodeRay{border-collapse:separate;border-spacing:0;margin-bottom:0;border:0;background:none}
+table.CodeRay td{vertical-align: top}
+table.CodeRay td.line-numbers{text-align:right}
+table.CodeRay td.line-numbers>pre{padding:0;color:rgba(0,0,0,.3)}
+table.CodeRay td.code{padding:0 0 0 .5em}
+table.CodeRay td.code>pre{padding:0}
+.CodeRay .debug{color:#fff !important;background:#000080 !important}
+.CodeRay .annotation{color:#007}
+.CodeRay .attribute-name{color:#000080}
+.CodeRay .attribute-value{color:#700}
+.CodeRay .binary{color:#509}
+.CodeRay .comment{color:#998;font-style:italic}
+.CodeRay .char{color:#04d}
+.CodeRay .char .content{color:#04d}
+.CodeRay .char .delimiter{color:#039}
+.CodeRay .class{color:#458;font-weight:bold}
+.CodeRay .complex{color:#a08}
+.CodeRay .constant,.CodeRay .predefined-constant{color:#008080}
+.CodeRay .color{color:#099}
+.CodeRay .class-variable{color:#369}
+.CodeRay .decorator{color:#b0b}
+.CodeRay .definition{color:#099}
+.CodeRay .delimiter{color:#000}
+.CodeRay .doc{color:#970}
+.CodeRay .doctype{color:#34b}
+.CodeRay .doc-string{color:#d42}
+.CodeRay .escape{color:#666}
+.CodeRay .entity{color:#800}
+.CodeRay .error{color:#808}
+.CodeRay .exception{color:inherit}
+.CodeRay .filename{color:#099}
+.CodeRay .function{color:#900;font-weight:bold}
+.CodeRay .global-variable{color:#008080}
+.CodeRay .hex{color:#058}
+.CodeRay .integer,.CodeRay .float{color:#099}
+.CodeRay .include{color:#555}
+.CodeRay .inline{color:#00}
+.CodeRay .inline .inline{background:#ccc}
+.CodeRay .inline .inline .inline{background:#bbb}
+.CodeRay .inline .inline-delimiter{color:#d14}
+.CodeRay .inline-delimiter{color:#d14}
+.CodeRay .important{color:#555;font-weight:bold}
+.CodeRay .interpreted{color:#b2b}
+.CodeRay .instance-variable{color:#008080}
+.CodeRay .label{color:#970}
+.CodeRay .local-variable{color:#963}
+.CodeRay .octal{color:#40e}
+.CodeRay .predefined{color:#369}
+.CodeRay .preprocessor{color:#579}
+.CodeRay .pseudo-class{color:#555}
+.CodeRay .directive{font-weight:bold}
+.CodeRay .type{font-weight:bold}
+.CodeRay .predefined-type{color:inherit}
+.CodeRay .reserved,.CodeRay .keyword {color:#000;font-weight:bold}
+.CodeRay .key{color:#808}
+.CodeRay .key .delimiter{color:#606}
+.CodeRay .key .char{color:#80f}
+.CodeRay .value{color:#088}
+.CodeRay .regexp .delimiter{color:#808}
+.CodeRay .regexp .content{color:#808}
+.CodeRay .regexp .modifier{color:#808}
+.CodeRay .regexp .char{color:#d14}
+.CodeRay .regexp .function{color:#404;font-weight:bold}
+.CodeRay .string{color:#d20}
+.CodeRay .string .string .string{background:#ffd0d0}
+.CodeRay .string .content{color:#d14}
+.CodeRay .string .char{color:#d14}
+.CodeRay .string .delimiter{color:#d14}
+.CodeRay .shell{color:#d14}
+.CodeRay .shell .delimiter{color:#d14}
+.CodeRay .symbol{color:#990073}
+.CodeRay .symbol .content{color:#a60}
+.CodeRay .symbol .delimiter{color:#630}
+.CodeRay .tag{color:#008080}
+.CodeRay .tag-special{color:#d70}
+.CodeRay .variable{color:#036}
+.CodeRay .insert{background:#afa}
+.CodeRay .delete{background:#faa}
+.CodeRay .change{color:#aaf;background:#007}
+.CodeRay .head{color:#f8f;background:#505}
+.CodeRay .insert .insert{color:#080}
+.CodeRay .delete .delete{color:#800}
+.CodeRay .change .change{color:#66f}
+.CodeRay .head .head{color:#f4f}
+body {
+ padding-top: 60px;
+ padding-bottom: 40px;
+}
+</style>
+<script type="text/javascript">
+
+ var _gaq = _gaq || [];
+ _gaq.push(['_setAccount', 'UA-36103647-1']);
+ _gaq.push(['_trackPageview']);
+
+ (function() {
+ var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
+ ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
+ var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
+ })();
+
+ </script>
+</head>
+
+<body>
+
+ <div class="navbar navbar-fixed-top">
+ <div class="navbar-inner">
+ <div class="container">
+ <a class="btn btn-navbar" data-toggle="collapse"
+ data-target=".nav-collapse"> <span class="icon-bar"></span> <span
+ class="icon-bar"></span> <span class="icon-bar"></span>
+ </a> <a class="brand logocolor"
+ href="http://deltaspike.apache.org/index.html">Apache
+ DeltaSpike</a>
+ <div class="nav-collapse">
+ <ul class="nav">
+ <li class="active"><a
+ href="http://deltaspike.apache.org/index.html">Home</a></li>
+ <li><a href="http://deltaspike.apache.org/documentation">Documentation</a></li>
+ <li><a href="http://deltaspike.apache.org/javadoc.html">Javadoc</a></li>
+ <li><a href="http://deltaspike.apache.org/documentation/source.html">Source</a></li>
+ <li><a href="http://deltaspike.apache.org/download.html">Download</a></li>
+ <li><a href="http://deltaspike.apache.org/community.html">Community</a></li>
+ <!-- <li><a href="./support.html">Support</a></li> -->
+ <li><a href="http://deltaspike.apache.org/news.html">News</a></li>
+ <li><a
+ href="http://deltaspike.apache.org/migration-guide.html">Migration</a></li>
+ </ul>
+ </div>
+ <!--/.nav-collapse -->
+ <form id="search-form" action="http://www.google.com/search"
+ method="get" class="navbar-search pull-right">
+ <input value="deltaspike.apache.org" name="sitesearch"
+ type="hidden"> <input class="search-query" name="q"
+ id="query" type="text">
+ </form>
+ </div>
+ </div>
+ </div>
+
+ <div class="container">
+ <div class="row">
+ <div class="span12">
+ <div class="page-title">
+ <h1>JSF</h1>
+ </div>
+
+ <div id="toc" class="toc">
+ <ul class="sectlevel1">
+<li><a href="#_multi_window_handling">Multi-Window Handling</a>
+<ul class="sectlevel2">
+<li><a href="#_intro">Intro</a>
+<ul class="sectlevel3">
+<li><a href="#_historic_considerations">Historic Considerations</a></li>
+<li><a href="#_how_jsf_2_changed_the_world">How JSF-2 changed the world</a></li>
+<li><a href="#_standard_windowid_handling">Standard windowId Handling</a></li>
+</ul>
+</li>
+<li><a href="#_available_modes">Available modes</a>
+<ul class="sectlevel3">
+<li><a href="#_clientwindow">CLIENTWINDOW</a></li>
+<li><a href="#_lazy">LAZY</a></li>
+<li><a href="#_none">NONE</a></li>
+<li><a href="#_delegated">DELEGATED</a></li>
+<li><a href="#_custom">CUSTOM</a></li>
+</ul>
+</li>
+<li><a href="#_configuration">Configuration</a>
+<ul class="sectlevel3">
+<li><a href="#_ds_windowid">ds:windowId</a></li>
+<li><a href="#_ds_disableclientwindow">ds:disableClientWindow</a></li>
+<li><a href="#_number_of_active_windows">Number of active windows</a></li>
+<li><a href="#_switch_mode">Switch Mode</a></li>
+<li><a href="#_provide_a_custom_clientwindow">Provide a custom ClientWindow</a></li>
+</ul>
+</li>
+<li><a href="#_based_scopes">Based Scopes</a></li>
+</ul>
+</li>
+<li><a href="#_scopes">Scopes</a>
+<ul class="sectlevel2">
+<li><a href="#__windowscoped">@WindowScoped</a></li>
+<li><a href="#__viewaccessscoped">@ViewAccessScoped</a></li>
+<li><a href="#__groupedconversationscoped_since_0_6">@GroupedConversationScoped (since 0.6)</a></li>
+<li><a href="#__viewscoped">@ViewScoped</a></li>
+<li><a href="#_jsf_2_0_scopes">JSF 2.0 Scopes</a></li>
+</ul>
+</li>
+<li><a href="#_integration_with_deltaspike_type_safe_messages">Integration with DeltaSpike type-safe messages</a></li>
+<li><a href="#_type_safe_view_configs">Type-safe View-Configs</a>
+<ul class="sectlevel2">
+<li><a href="#_intro_2">Intro</a></li>
+<li><a href="#_motivation">Motivation</a></li>
+<li><a href="#_bean_discovery_mode_annotated">Bean-discovery-mode annotated</a></li>
+<li><a href="#_basic_api_usages">Basic API usages</a>
+<ul class="sectlevel3">
+<li><a href="#_file_view_and_folder_folder_paths">File (@View) and Folder (@Folder) paths</a></li>
+<li><a href="#_navigation_parameters">Navigation Parameters</a></li>
+<li><a href="#_static_configuration_via_navigationparameter">Static Configuration via @NavigationParameter</a></li>
+<li><a href="#_security_integration_via_secured">Security Integration via @Secured</a></li>
+<li><a href="#_view_controller_callbacks_via_viewcontrollerref">View-Controller Callbacks via @ViewControllerRef</a></li>
+<li><a href="#_referencing_views_via_viewref">Referencing Views via @ViewRef</a></li>
+<li><a href="#_using_the_optional_viewnavigationhandler">Using the (optional) ViewNavigationHandler</a></li>
+<li><a href="#_configuring_a_default_error_view">Configuring a Default Error-View</a></li>
+<li><a href="#_using_matches">Using @Matches</a></li>
+<li><a href="#_using_viewconfigresolver">Using ViewConfigResolver</a></li>
+</ul>
+</li>
+<li><a href="#_advanced_api_usages">Advanced API usages</a>
+<ul class="sectlevel3">
+<li><a href="#_creating_custom_meta_data_via_viewmetadata">Creating Custom Meta-Data via @ViewMetaData</a></li>
+<li><a href="#_creating_custom_meta_data_via_stereotype">Creating Custom Meta-Data via @Stereotype</a></li>
+<li><a href="#_creating_custom_callbacks_via_viewmetadata">Creating Custom Callbacks via @ViewMetaData</a></li>
+<li><a href="#_creating_custom_inline_meta_data_via_inlineviewmetadata">Creating Custom inline Meta-Data via @InlineViewMetaData</a></li>
+</ul>
+</li>
+<li><a href="#_path_validation">Path-Validation</a></li>
+<li><a href="#_view_config_spi">View-Config SPI</a>
+<ul class="sectlevel3">
+<li><a href="#_configdescriptorvalidator">ConfigDescriptorValidator</a></li>
+<li><a href="#_confignodeconverter">ConfigNodeConverter</a></li>
+<li><a href="#_configpreprocessor">ConfigPreProcessor</a></li>
+<li><a href="#_inlinemetadatatransformer">InlineMetaDataTransformer</a></li>
+<li><a href="#_targetviewconfigprovider">TargetViewConfigProvider</a></li>
+<li><a href="#_viewconfiginheritancestrategy">ViewConfigInheritanceStrategy</a></li>
+<li><a href="#_viewconfignode">ViewConfigNode</a></li>
+<li><a href="#__viewconfigroot">@ViewConfigRoot</a></li>
+</ul>
+</li>
+<li><a href="#_activation_of_custom_naming_conventions">Activation of custom naming conventions</a></li>
+</ul>
+</li>
+<li><a href="#__grouped_conversations">(Grouped-)Conversations</a>
+<ul class="sectlevel2">
+<li><a href="#_terminating_conversations">Terminating Conversations</a></li>
+<li><a href="#_sub_conversation_groups">Sub-Conversation-Groups</a></li>
+</ul>
+</li>
+<li><a href="#_injection_in_jsf_artifacts_todo">Injection in JSF Artifacts (TODO)</a>
+<ul class="sectlevel2">
+<li><a href="#_converter_validator">Converter & Validator</a></li>
+<li><a href="#_phaselistener">PhaseListener</a></li>
+</ul>
+</li>
+<li><a href="#_event_broadcasting">Event broadcasting</a>
+<ul class="sectlevel2">
+<li><a href="#_beforejsfrequest_afterjsfrequest_todo">BeforeJsfRequest / AfterJsfRequest (TODO)</a></li>
+<li><a href="#_beforephase_afterphase_todo">BeforePhase / AfterPhase (TODO)</a></li>
+<li><a href="#_jsf_systemevents">JSF SystemEvents</a></li>
+</ul>
+</li>
+<li><a href="#_intergration_with_exception_control_since_0_6">Intergration with Exception Control (since 0.6)</a>
+<ul class="sectlevel2">
+<li><a href="#_examples">Examples</a>
+<ul class="sectlevel3">
+<li><a href="#_basic">Basic</a></li>
+<li><a href="#_redirect">Redirect</a></li>
+</ul>
+</li>
+<li><a href="#_using_a_custom_qualifier_for_jsf_exceptions">Using a custom qualifier for JSF Exceptions</a></li>
+</ul>
+</li>
+<li><a href="#_double_submit_prevention">Double-Submit prevention</a></li>
+<li><a href="#_support_of_ear_deployments">Support of EAR deployments</a></li>
+<li><a href="#_hints">Hints</a></li>
+</ul>
+ <hr>
+
+ <div class="sect1">
+<h2 id="_multi_window_handling">Multi-Window Handling</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_intro">Intro</h3>
+<div class="sect3">
+<h4 id="_historic_considerations">Historic Considerations</h4>
+<div class="paragraph">
+<p>Until the end of the 1990s web browsers are usually single threaded and
+only had one window. But in the last years browsers supporting multiple
+windows or even tab became the standard. Since those days lots of
+efforts went into uniquely identifying a single browser window on the
+server side. Sadly browser windows still lack of a native windowId, thus
+maintaining web application data in @SessionScoped backing beans is
+still used in most of the cases.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_how_jsf_2_changed_the_world">How JSF-2 changed the world</h4>
+<div class="paragraph">
+<p>The MyFaces Orchestra community did a good summary about the various
+ways to handle multiple window support in JSF Applications. Those
+findings are still valid and up to date, but the environmental
+conditions have changed slightly since then. It is easy to pass a
+windowId around with a POST request, but it gets tricky with GET
+requests. Due to the new JSF-2 ability to use bookmarkable URLs and deep
+links, a typical JSF-2 application contains much more GET links than we
+used to see in JSF-1, thus we have far more href links to cope with.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_standard_windowid_handling">Standard windowId Handling</h4>
+<div class="paragraph">
+<p>With a classical approach we would not be able to simply add a windowId
+parameter to such links because if the user would open the link in a new
+browser window or tab, we would carry the windowId - and thus the window
+scope - over to the new browser tab/window. The classic solution was to
+omit the windowId for all GET links, but by doing this we would now
+loose the window scope far too often with JSF-2! Marios summary also
+contains a method to prevent this problem by storing a value directly in
+the browser window via JavaScript. Usually this is rendered and executed
+in the same page as the user form. See the "Post-render window
+detection" paragraph for a more detailed description. The major downside
+of this solution is that we might already pollute 'foreign' beans (and
+destroy their information) while rendering the page, which means this is
+not feasible as general solution.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_available_modes">Available modes</h3>
+<div class="sect3">
+<h4 id="_clientwindow">CLIENTWINDOW</h4>
+<div class="paragraph">
+<p>Each GET request results in an intermediate small html page which checks
+if the browser tab fits the requested windowId. When the windowId is
+valid, a unique token (called <code>dsRid</code>) will be generated for the current
+request and added to the URL. In addition a cookie with with the
+dsRid/windowId will be added. On the server side, the verified windowId
+will be extracted from the cookie. For POST request detection, the
+windowId will be added as hidden input to all forms.</p>
+</div>
+<div class="sect4">
+<h5 id="_advantage">Advantage</h5>
+<div class="ulist">
+<ul>
+<li>
+<p>Covers all edge cases</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="_disadvantage">Disadvantage</h5>
+<div class="ulist">
+<ul>
+<li>
+<p>Having the windowhandler.html site rendered between requests sometimes
+leads to some 'flickering' if the destination page takes some time to
+load. The browser first renders our windowhandler and only after that
+the original page will get loaded. This effect may be minimized by
+branding the windowhandler.html page and providing an own one with a
+bgcolor which matches your application. For html-5 aware browsers we
+also got rid of this flickering by storing away a 'screenshot' of the
+first page in onclick() and immediately restore this 'screenshot' on the
+intermediate windowhandler.html page. Technically we do this by storing
+away the and css information into the html5 localStorage and restore them on the
+intermediate page. We also introduced a WindowConfig which is able to
+parse a request and decide upon the UserAgent or any other information
+if a client will get an intermediate page or if he gets the result page
+directly.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="_change_windowhandler_html">Change windowhandler.html</h5>
+<div class="paragraph">
+<p>To customize the look & feel of the windowhandler.html, you can simply
+provide a own via:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Specializes</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyClientWindowConfig</span> <span class="directive">extends</span> DefaultClientWindowConfig
+{
+ <span class="annotation">@Override</span>
+ <span class="directive">public</span> <span class="predefined-type">String</span> getClientWindowHtml()
+ {
+ <span class="keyword">return</span> <span class="string"><span class="delimiter">"</span><span class="content"><html><body>Loading...</body></html></span><span class="delimiter">"</span></span>;
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_lazy">LAZY</h4>
+<div class="paragraph">
+<p>Always appends the windowId to all, from JSF generated, URLs. On the
+first GET request without a windowId, it will generate a new windowId
+and redirect, with the windowId in the URL, to the same view again. The
+current windowId will be stored in the <code>window.name</code> variable on the
+client side. For all further requests, a lazy check will be performed to
+check if the windowId in the URL is matching with the <code>window.name</code>. If
+it’s not matching, the view will be refreshed with the right windowId in
+the URL.</p>
+</div>
+<div class="sect4">
+<h5 id="_advantage_2">Advantage</h5>
+<div class="ulist">
+<ul>
+<li>
+<p>No windowhandler.html / loading screen required</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="_disadvantage_2">Disadvantage</h5>
+<div class="ulist">
+<ul>
+<li>
+<p>It could happen that 2 tabs will share the same windowId for 1 request
+because the <code>LAZY</code> mode will check lazily, after rendering the view, if
+the windowId matches the <code>window.name</code>. Therefore it could happen that
+@ViewAccessScoped or other scopes will unintentionally be destroyed.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="_workflow_example">Workflow example</h5>
+<div class="paragraph">
+<p>First GET request with windowId</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Renders the view</p>
+</li>
+<li>
+<p>Stores the windowId as <code>window.name</code> on the client side</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>First GET request without windowId</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Redirect to the same view with a new windowId in the URL</p>
+</li>
+<li>
+<p>Renders the view</p>
+</li>
+<li>
+<p>Stores the windowId as <code>window.name</code> on the client side</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Further GET request with windowId</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Renders the view</p>
+</li>
+<li>
+<p>Checks if the requested windowId matches the <code>window.name</code></p>
+</li>
+<li>
+<p>If it does not match, reload the URL with the right windowId taken
+from <code>window.name</code></p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Further GET request without windowId</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Redirect to the same view with a new windowId in the URL</p>
+</li>
+<li>
+<p>Renders the view</p>
+</li>
+<li>
+<p>If it does not match, reload the URL with the right windowId taken
+from <code>window.name</code></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_none">NONE</h4>
+<div class="paragraph">
+<p>Any window or browser tab detection will be disabled for the current
+request. Scopes like @WindowScoped, @GroupedConversationScoped or
+@ViewAccessScoped will not work. This is also the default mode if the
+current request doesn’t support Javascript or if the user agent is a
+bot/crawler.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_delegated">DELEGATED</h4>
+<div class="paragraph">
+<p>Delegates the complete window handling to the new JSF 2.2 ClientWindow
+(if not disabled).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_custom">CUSTOM</h4>
+<div class="paragraph">
+<p>Enables to use an complete own
+<code>org.apache.deltaspike.jsf.spi.scope.window.ClientWindow</code>
+implementation.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_configuration">Configuration</h3>
+<div class="sect3">
+<h4 id="_ds_windowid">ds:windowId</h4>
+<div class="paragraph">
+<p>The component <code>ds:windowId</code>
+(<code>xmlns:ds="http://deltaspike.apache.org/jsf"</code>) is required to enable
+the full control of the DeltaSpike window handling. It will import and
+render the required script parts for both <code>LAZY</code> and <code>CLIENTWINDOW</code>
+mode. The best way, to apply it for all views, is to add this component
+to all of your templates.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_ds_disableclientwindow">ds:disableClientWindow</h4>
+<div class="paragraph">
+<p>Similiar to JSF 2.2' <code>disableClientWindow</code> attribute,
+<code>ds:disableClientWindow</code> provides the ability to disable the rendering
+of the windowId to all links of all child components:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="xml"><span class="tag"><ds:disableClientWindow></span>
+ <span class="tag"><h:link</span> <span class="attribute-name">value</span>=<span class="string"><span class="delimiter">"</span><span class="content">Link without windowId</span><span class="delimiter">"</span></span> <span class="attribute-name">outcome</span>=<span class="string"><span class="delimiter">"</span><span class="content">target.xhtml</span><span class="delimiter">"</span></span> <span class="tag">/></span>
+<span class="tag"></ds:disableClientWindow></span>
+<span class="tag"><h:link</span> <span class="attribute-name">value</span>=<span class="string"><span class="delimiter">"</span><span class="content">Link with windowId</span><span class="delimiter">"</span></span> <span class="attribute-name">outcome</span>=<span class="string"><span class="delimiter">"</span><span class="content">target.xhtml</span><span class="delimiter">"</span></span><span class="tag">/></span></code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_number_of_active_windows">Number of active windows</h4>
+<div class="paragraph">
+<p>By default, DeltaSpike allows <code>1024</code> active windows per session. Anyway, this number is reduced inside this JSF module to <code>64</code> for JSF applications. Once that the limit number of active windows is reached, DeltaSpike will drop the oldest active window.</p>
+</div>
+<div class="paragraph">
+<p>You can change the default value by setting the property <code>deltaspike.scope.window.max-count</code> using <a href="configuration.html#_configsources_provided_by_default">DeltaSpike configuration mechanism</a>.</p>
+</div>
+<div class="paragraph">
+<p>You can also provide this value via:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Specializes</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyClientWindowConfig</span> <span class="directive">extends</span> DefaultClientWindowConfig
+{
+
+ <span class="annotation">@Override</span>
+ <span class="directive">public</span> <span class="type">int</span> getMaxWindowContextCount()
+ {
+ <span class="comment">// return the max active windows per session</span>
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_switch_mode">Switch Mode</h4>
+<div class="paragraph">
+<p>To switch the mode, just provide a
+<code>org.apache.deltaspike.jsf.api.config.JsfModuleConfig</code> and overwrite
+<code>#getDefaultWindowMode</code>:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Specializes</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyJsfModuleConfig</span> <span class="directive">extends</span> JsfModuleConfig
+{
+ <span class="annotation">@Override</span>
+ <span class="directive">public</span> ClientWindowConfig.ClientWindowRenderMode getDefaultWindowMode()
+ {
+ <span class="comment">//...</span>
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_provide_a_custom_clientwindow">Provide a custom ClientWindow</h4>
+<div class="paragraph">
+<p>If you would like to provide an custom
+<code>org.apache.deltaspike.jsf.spi.scope.window.ClientWindow</code>
+implementation, you can just do it e.g. via CDI alternatives:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@ApplicationScoped</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyClientWindow</span> <span class="directive">implements</span> ClientWindow
+{
+ <span class="comment">//...</span>
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Don’t forget to set the <code>ClientWindowRenderMode</code> to 'CUSTOM' via the
+<code>JsfModuleConfig</code>:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Specializes</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyJsfModuleConfig</span> <span class="directive">extends</span> JsfModuleConfig
+{
+ <span class="annotation">@Override</span>
+ <span class="directive">public</span> ClientWindowConfig.ClientWindowRenderMode getDefaultWindowMode()
+ {
+ <span class="keyword">return</span> ClientWindowConfig.ClientWindowRenderMode.CUSTOM;
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_based_scopes">Based Scopes</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>@WindowScoped</p>
+</li>
+<li>
+<p>@ViewAccessScoped</p>
+</li>
+<li>
+<p>@GroupedConversationScoped</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_scopes">Scopes</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="__windowscoped">@WindowScoped</h3>
+<div class="paragraph">
+<p>The window-scope is like a session per window. That means that the data
+is bound to a window/tab and it not shared between windows (like the
+session scope does). Usually you need the window-scope instead of the
+session-scope. There aren’t a lot of use-cases which need shared data
+between windows.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@WindowScoped</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">PreferencesBean</span> <span class="directive">implements</span> <span class="predefined-type">Serializable</span>
+{
+ <span class="comment">//...</span>
+}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="__viewaccessscoped">@ViewAccessScoped</h3>
+<div class="paragraph">
+<p>In case of conversations you have to un-scope beans manually (or they
+will be terminated automatically after a timeout). However, sometimes
+you need beans with a lifetime which is as long as needed and as short
+as possible - which are terminated automatically (as soon as possible).
+In such an use-case you can use this scope. The simple rule is, as long
+as the bean is referenced by a page - the bean will be available for the
+next page (if it’s used again the bean will be forwarded again). It is
+important that it’s based on the view-id of a page (it isn’t based on
+the request) so e.g. Ajax requests don’t trigger a cleanup if the
+request doesn’t access all view-access scoped beans of the page. That’s
+also the reason for the name @<em>View</em>AccessScoped.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@ViewAccessScoped</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">WizardBean</span> <span class="directive">implements</span> <span class="predefined-type">Serializable</span>
+{
+ <span class="comment">//...</span>
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Hint: @ViewAccessScoped beans are best used in conjunction with the
+<code>CLIENTWINDOW</code> window handling, which ensures a clean browser-tab
+separation without touching the old windowId. Otherwise a 'open in new
+tab' on a page with a @ViewAccessScoped bean might cause the termination
+(and re-initialization) of that bean.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="__groupedconversationscoped_since_0_6">@GroupedConversationScoped (since 0.6)</h3>
+<div class="paragraph">
+<p>See (Grouped-)Conversations</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="__viewscoped">@ViewScoped</h3>
+<div class="paragraph">
+<p>DeltaSpike provides an CDI context for the JSF 2.0/2.1
+@javax.faces.bean.ViewScoped. You can simply annotate your bean with
+@javax.faces.bean.ViewScoped and @Named.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jsf_2_0_scopes">JSF 2.0 Scopes</h3>
+<div class="paragraph">
+<p>JSF 2.0 introduced new annotations as well as a new scope - the View
+Scope. CODI allows to use all the CDI mechanisms in beans annotated
+with:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>javax.faces.bean.ApplicationScoped</p>
+</li>
+<li>
+<p>javax.faces.bean.SessionScoped</p>
+</li>
+<li>
+<p>javax.faces.bean.RequestScoped</p>
+</li>
+<li>
+<p>javax.faces.bean.ViewScoped</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Furthermore, the managed-bean annotation (javax.faces.bean.ManagedBean)
+is mapped to @Named from CDI.</p>
+</div>
+<div class="paragraph">
+<p>All these annotations are mapped automatically. So you won’t face
+issues, if you import a JSF 2 annotation instead of the corresponding
+CDI annotation.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_integration_with_deltaspike_type_safe_messages">Integration with DeltaSpike type-safe messages</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>You can use <a href="core.html#_messages_i18n">DeltaSpike type-safe messages</a>
+with JSF to provide i18n messages and test to an JSF appplicaton.</p>
+</div>
+<div class="paragraph">
+<p>JSF module is also capable to use messages provided through in
+faces-config.xml file. The element allows you to override JSF default
+messages (Section 2.5.2.4 of the JSF specification contains the list of
+all JSF default messages that could be override.).</p>
+</div>
+<div class="paragraph">
+<p>DeltaSpike can also reuse the same file to provide type-safe messages so
+you don’t have to use the naming convention nor <code>@MessageContextConfig</code>.
+If there is a config for supported locales it will be checked as well
+and fallback to the configured default locale.</p>
+</div>
+<div class="paragraph">
+<p>Example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@MessageBundle</span>
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">SimpleMessage</span>
+{
+ <span class="annotation">@MessageTemplate</span>(<span class="string"><span class="delimiter">"</span><span class="content">{welcome_to_deltaspike}</span><span class="delimiter">"</span></span>)
+ <span class="predefined-type">String</span> welcomeToDeltaSpike();
+}
+
+<span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">PageBean</span>
+{
+
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> SimpleMessage messages;
+
+ <span class="directive">public</span> <span class="type">void</span> actionMethod(){
+ FacesContext.getCurrentInstance().addMessage(<span class="predefined-constant">null</span>,<span class="keyword">new</span> FacesMessage(messages.welcomeToDeltaSpike()));
+ }
+
+}
+
+
+org.apache.deltaspike.example.message.SimpleMessage
+
+->
+
+org/apache/deltaspike/example/message/SimpleMessage.properties
+org/apache/deltaspike/example/message/SimpleMessage.properties
+org/apache/deltaspike/example/message/SimpleMessage_en.properties
+org/apache/deltaspike/example/message/SimpleMessage_de.properties
+
+...
+
+<span class="comment">//content (as usual in message bundle files):</span>
+welcome_to_deltaspike=Welcome to DeltaSpike
+<span class="comment">//Overrided JSF messages</span>
+javax.faces.component.UIInput.REQUIRED = {<span class="integer">0</span>}: Please enter a value</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>On faces-config.xml file:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="xml"><span class="tag"><faces-config></span>
+ <span class="tag"><application></span>
+ <span class="tag"><message-bundle></span>org.apache.deltaspike.example.message.SimpleMessage<span class="tag"></message-bundle></span>
+ <span class="tag"></application></span>
+<span class="tag"></faces-config></span></code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_type_safe_view_configs">Type-safe View-Configs</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_intro_2">Intro</h3>
+<div class="paragraph">
+<p>Type-safe view-configs are static configs which can be used in
+combination with every view-technology which is based on Java. Currently
+DeltaSpike itself provides an integration for JSF, however, the basic
+concepts are independent of it. (Since DeltaSpike provides the default
+integration only for JSF, the whole documentation for view-configs is
+located here.)</p>
+</div>
+<div class="paragraph">
+<p>Thanks to features like multiple (meta-data-)inheritance via interfaces,
+it provides a powerful approach to bind meta-data to one or multiple
+views. In case of the JSF integration it’s possible to provide e.g.
+type-safe meta-data for security, navigation, callbacks for
+view-controllers. Beyond configuring view (/pages) via this concept,
+it’s also possible to use the (view-)config classes for type-safe
+navigation. Since it’s std. Java, you can benefit from any Java-IDE and
+you don’t need special IDE-Addons to use it efficiently.</p>
+</div>
+<div class="paragraph">
+<p>Even the concepts provided by modules (of DeltaSpike itself) are based
+on the basic API provided by the Core. So it’s possible to introduce
+custom concepts the same way DeltaSpike itself does.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_motivation">Motivation</h3>
+<div class="paragraph">
+<p>Instead of learning the concepts and rules of view-configs provided by
+DeltaSpike, it might be easier for simple demos to just type some
+simple(r) strings. So why should you use something which is slightly
+more work <strong>initially</strong>?</p>
+</div>
+<div class="paragraph">
+<p><strong>The short answer is:</strong></p>
+</div>
+<div class="paragraph">
+<p>It gives a good return in case of real applications (esp. beyond simple demos).</p>
+</div>
+<div class="paragraph">
+<p><strong>The long answer is:</strong></p>
+</div>
+<div class="paragraph">
+<p>You can benefit from it from the first second:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>It’s type-safe →</p>
+<div class="ulist">
+<ul>
+<li>
+<p>the Java compiler ensures that you don’t have typos at the final usages (and the rest can be checked during bootstrapping of the application)</p>
+</li>
+<li>
+<p>you can benefit from the auto.complete features of any modern Java IDE.</p>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>If you change the name of a file/folder, you need only one (easy) code-change in a single place and your (std. Java-) IDE will do the rest for you (= update all usages) without a special plug-in</p>
+</li>
+<li>
+<p>It’s possible to restrict the navigation target → you can ensure that the navigation target is still the intended one (e.g. after a refactoring)</p>
+</li>
+<li>
+<p>You can configure meta-data in a central place (which can get inherited via <strong>multiple</strong> inheritance based on Java interfaces)</p>
+</li>
+<li>
+<p>Easier for developers to find usages</p>
+</li>
+<li>
+<p>Allows easy(er) refactorings and maintenance</p>
+</li>
+<li>
+<p>You can use your IDE more efficiently esp. in large projects (there are some users who initially switched to it, because their tools for displaying the config they had before open large config files very slowly…​)</p>
+</li>
+<li>
+<p>Modern Java IDEs show inheritance of interfaces and classes in a nice way. Since the view-config is based on std. classes and interfaces, you can benefit from it easily.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Advantages which are planned for later (= currently not supported):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>It’s possible to check if the configured folders and files really exist during/after the bootstrapping phase of the application (currently it isn’t implemented, but it’s possible to do it).</p>
+</li>
+<li>
+<p>It’s also easy(er) for tools (IDE plugins,…​) to validate it</p>
+</li>
+<li>
+<p>It’s possible to validate the config (if the corresponding path (view or folder) really exists (after v0.5 it’s done out-of-the-box)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>If you are still not convinced, you just have to try it. You will see how your daily workflow benefits from it pretty soon.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_bean_discovery_mode_annotated">Bean-discovery-mode annotated</h3>
+<div class="paragraph">
+<p>CDI 1.1 introduced a concept called bean-discovery-mode. If you would
+like to use the mode <code>annotated</code>, please have a look at the hint at
+@ViewConfigRoot</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_basic_api_usages">Basic API usages</h3>
+<div class="paragraph">
+<p>While reading this section keep the following simple rules in mind:
+Meta-data gets inherited along the path of Java inheritance
+File-/Folder- paths are build based on nesting classes and interfaces
+Usually users don’t need to be aware of all descriptors, SPIs,…​ which
+are described by this documentation.</p>
+</div>
+<div class="paragraph">
+<p>There are a lot of possibilities to configure views and some of them are
+optional. The following examples show some of them in combination with
+features provided by the JSF- and Security-Module of DeltaSpike.</p>
+</div>
+<div class="paragraph">
+<p>The following example shows the minimal syntax for providing a config
+for a view (/page).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">class</span> <span class="class">MyPage</span> <span class="directive">implements</span> ViewConfig
+{
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Since it’s a class (and not an interface) it’s autom. recognized as
+config for a page (and not a folder) and the default settings get
+applied during bootstrapping. In case of JSF you can use it for
+navigation e.g. via action-methods.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> toNextPage()
+{
+ <span class="keyword">return</span> MyPage.class;
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This leads to a forward to <code>/myPage.xhtml</code>. Information like base-path,
+file- (and folder-)name/s, file-extension, navigation mode,
+view-params,…​ can be customized with the corresponding
+(meta-data-)annotations. One of those annotations provided by the JSF
+module (which is optional) is <code>@View</code>. That means the following example
+leads to the same as the first one.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@View</span> <span class="comment">//optional</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyPage</span> <span class="directive">implements</span> ViewConfig
+{
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>But it’s also possible to reflect the folder structure via nesting of
+interfaces and classes. An example for it is:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="type">interface</span> <span class="class">AdminArea</span> <span class="directive">extends</span> ViewConfig
+ {
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Admin { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In case of the JSF integration it leads to the following view-ids:
+/pages/index.xhtml /pages/adminArea/index.xhtml</p>
+</div>
+<div class="paragraph">
+<p>Like the optional <code>@View</code> for pages represented by the classes, it’s
+possible to use the optional <code>@Folder</code> annotation for directories
+represented by the (nested) interfaces.</p>
+</div>
+<div class="paragraph">
+<p>Furthermore, it’s possible to inherit meta-data along with the normal
+inheritance.</p>
+</div>
+<div class="paragraph">
+<p>In the following example <code>Pages.Admin.Index</code>, <code>Pages.Admin.Home</code> and
+<code>Pages.Admin.Statistics.Home</code> inherit the meta-data from <code>Pages.Admin</code>
+because they implement the interface whereas
+<code>Pages.Admin.Statistics.Index</code> doesn’t. However, <code>Pages.Admin.Home</code>
+overrides <code>View#navigation</code>. During the bootstrapping process the
+meta-data gets merged and at runtime you only see the final result
+(which is cached).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="annotation">@View</span>(name = <span class="string"><span class="delimiter">"</span><span class="content">home</span><span class="delimiter">"</span></span>, extension = JSP)
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="annotation">@View</span>(navigation = REDIRECT, viewParams = INCLUDE)
+ <span class="type">interface</span> <span class="class">Admin</span> <span class="directive">extends</span> ViewConfig
+ {
+ <span class="type">interface</span> <span class="class">Statistics</span>
+ {
+ <span class="annotation">@View</span> <span class="comment">//optional</span>
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="type">class</span> <span class="class">Home</span> <span class="directive">implements</span> Admin { }
+ }
+
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Admin { }
+
+ <span class="annotation">@View</span>(navigation = FORWARD)
+ <span class="type">class</span> <span class="class">Home</span> <span class="directive">implements</span> Admin { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In this case <code>Pages.Admin.Statistics</code> is just an interface to reflect
+the folder structure. For sure it’s also possible that it extends an
+existing view-config interface and other folders and/or pages inherit
+its meta-data (like <code>Pages.Admin</code>).</p>
+</div>
+<div class="paragraph">
+<p>Furthermore, inheritance can be used to ensure navigation to the correct
+area in the application. In the following example the return type of the
+action-method (and therefore the compiler of Java) ensures that the
+navigation target of this method is within the admin-area.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> Pages.Admin> toNextPage()
+{
+ <span class="keyword">return</span> Pages.Admin.Index.class;
+}</code></pre>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_file_view_and_folder_folder_paths">File (@View) and Folder (@Folder) paths</h4>
+<div class="paragraph">
+<p><code>@View</code> as well as <code>@Folder</code> are optional annotations. <code>@Folder</code> is only
+needed for using a different folder-name or for marking folder configs
+if they don’t inherit from
+<code>org.apache.deltaspike.core.api.config.view.ViewConfig</code> <strong>nor</strong> have a
+view-config for a page nested into them (like Pages.Wizard1.Step1). If
+it isn’t used explicitly, it gets added automatically (so you can query
+the meta-data at runtime even in cases you haven’t placed the
+annotations explicitly). <code>@View</code> allows to customize a bit more and it
+also gets added automatically if it isn’t used explicitly. Whereas
+<code>@Folder</code> gets added to all nested interfaces (above a view-config class
+- like Pages and Pages.Wizard1), <code>@View</code> only gets added to classes
+which in-/directly inherit from
+<code>org.apache.deltaspike.core.api.config.view.ViewConfig</code> (like
+Pages.Wizard1.Step1).</p>
+</div>
+<div class="paragraph">
+<p>That means at runtime the following two configs lead to the same.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="type">interface</span> <span class="class">Wizard1</span>
+ {
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> ViewConfig { }
+ }
+}
+
+<span class="comment">//leads to the same as</span>
+
+<span class="annotation">@Folder</span>
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="annotation">@Folder</span>
+ <span class="type">interface</span> <span class="class">Wizard1</span>
+ {
+ <span class="annotation">@View</span>
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> ViewConfig { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The example above leads to the following paths:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>/pages/</p>
+</li>
+<li>
+<p>/pages/wizard1</p>
+</li>
+<li>
+<p>/pages/wizard1/step1.xhtml</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>To customize it you can use <code>@Folder#name</code>, <code>@View#basePath</code>,
+<code>@View#name</code> and <code>@View#extension</code> (or you register custom
+`NameBuilder`s inline or globally).</p>
+</div>
+<div class="sect4">
+<h5 id="__folder_name">@Folder#name</h5>
+<div class="paragraph">
+<p>The rules are pretty simple. You will get what you write. There are only
+two additional features:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>You don’t have to care about duplicated '/' (e.g. /folder1//folder2/step1.xhtml would get corrected auto. to /folder1/folder2/step1.xhtml)</p>
+</li>
+<li>
+<p>With "." at the beginning (e.g. "./") you can keep the path before.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The following example</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="annotation">@Folder</span>(name = <span class="string"><span class="delimiter">"</span><span class="content">/w1/</span><span class="delimiter">"</span></span>)
+ <span class="type">interface</span> <span class="class">Wizard1</span>
+ {
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> ViewConfig { }
+ }
+
+ <span class="annotation">@Folder</span>(name = <span class="string"><span class="delimiter">"</span><span class="content">./w2/</span><span class="delimiter">"</span></span>)
+ <span class="type">interface</span> <span class="class">Wizard2</span> <span class="directive">extends</span> ViewConfig
+ {
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> Wizard2 { } <span class="comment">//ViewConfig is inherited indirectly</span>
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>leads to the following paths:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>/pages/</p>
+</li>
+<li>
+<p>/w1/</p>
+</li>
+<li>
+<p>/w1/step1.xhtml</p>
+</li>
+<li>
+<p>/pages/w2/step1.xhtml</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect4">
+<h5 id="__view">@View</h5>
+<div class="paragraph">
+<p>The same naming rules apply to <code>@View#basePath</code>. However, it’s only
+valid to be used at view-config nodes which represent pages (→ classes
+and not interfaces). On interfaces always use <code>@Folder</code>
+(<code>@View#basePath</code> will get ignored there).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="type">interface</span> <span class="class">Pages</span>
+{
+ <span class="type">interface</span> <span class="class">Wizard1</span>
+ {
+ <span class="annotation">@View</span> <span class="comment">//optional</span>
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step2</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">./</span><span class="delimiter">"</span></span>) <span class="comment">//or just "."</span>
+ <span class="type">class</span> <span class="class">Step3</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">/w1/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step4</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">./w1/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step5</span> <span class="directive">implements</span> ViewConfig { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>leads to the following paths:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>/pages</p>
+</li>
+<li>
+<p>/pages/wizard1/</p>
+</li>
+<li>
+<p>/pages/wizard1/step1.xhtml</p>
+</li>
+<li>
+<p>/step2.xhtml</p>
+</li>
+<li>
+<p>/pages/wizard1/step3.xhtml</p>
+</li>
+<li>
+<p>/w1/step4.xhtml</p>
+</li>
+<li>
+<p>/pages/wizard/w1/step5.xhtml</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>and depending on additional meta-data you would like to inherit (e.g.
+<code>@View(navigation = REDIRECT)</code>), you can also use:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@View</span>(navigation = REDIRECT)
+<span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="type">interface</span> <span class="class">Wizard1</span> <span class="directive">extends</span> Pages
+ {
+ <span class="annotation">@View</span>
+ <span class="type">class</span> <span class="class">Step1</span> <span class="directive">implements</span> Wizard1 { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step2</span> <span class="directive">implements</span> Wizard1 { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">./</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step3</span> <span class="directive">implements</span> Wizard1 { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">/w1/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step4</span> <span class="directive">implements</span> Wizard1 { }
+
+ <span class="annotation">@View</span>(basePath = <span class="string"><span class="delimiter">"</span><span class="content">./w1/</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Step5</span> <span class="directive">implements</span> Wizard1 { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>It leads to the same paths, but in addition <code>@View#navigation</code> gets
+inherited along the inheritance path.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_navigation_parameters">Navigation Parameters</h4>
+<div class="paragraph">
+<p>Since the view-config is static, an approach to add parameters is
+needed. The following part shows different possibilities to add
+parameters which end up in the final URL after '?' (in case of the
+integration with JSF). It isn’t needed to add all (types of) parameters
+that way. Some get added autom. based on special meta-data (e.g.
+<code>@View#navigation</code> and <code>@View#viewParams</code>). Instead of adding
+<code>"faces-redirect=true"</code> manually it’s done for you as soon as you are
+using <code>@View(navigation = REDIRECT)</code>. The same goes for
+<code>"includeViewParams=true"</code> and <code>@View(viewParams = INCLUDE)</code>.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_static_configuration_via_navigationparameter">Static Configuration via @NavigationParameter</h4>
+<div class="paragraph">
+<p>In some cases it’s needed to add an information in any case. So you can
+annotate the view-config class with <code>@NavigationParameter</code>. Supported
+values are static strings or EL-expressions.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param1</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">staticValue1</span><span class="delimiter">"</span></span>)
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Pages { }
+
+ <span class="annotation">@NavigationParameter</span>.List({
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param1</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">staticValue1</span><span class="delimiter">"</span></span>),
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param2</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">#{myBean.property1}</span><span class="delimiter">"</span></span>)
+ })
+ <span class="type">class</span> <span class="class">Overview</span> <span class="directive">implements</span> Pages { }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Instead of using parameters in any case, it’s also possible to configure
+them statically for particular methods:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">PageBean</span>
+{
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param2</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">#{myBean.property1}</span><span class="delimiter">"</span></span>)
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> actionMethod1()
+ {
+ <span class="keyword">return</span> SimplePageConfig.class;
+ }
+
+ <span class="annotation">@NavigationParameter</span>.List({
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param1</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">staticValue1</span><span class="delimiter">"</span></span>),
+ <span class="annotation">@NavigationParameter</span>(key = <span class="string"><span class="delimiter">"</span><span class="content">param2</span><span class="delimiter">"</span></span>, value = <span class="string"><span class="delimiter">"</span><span class="content">staticValue2</span><span class="delimiter">"</span></span>)
+ })
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> actionMethod2()
+ {
+ <span class="keyword">return</span> SimplePageConfig.class;
+ }
+}</code></pre>
+</div>
+</div>
+<div class="sect4">
+<h5 id="_dynamic_configuration_via_navigationparametercontext">Dynamic Configuration via NavigationParameterContext</h5>
+<div class="paragraph">
+<p>Instead of using parameters in a static fashion (as shown above), it’s
+also possible to add them dynamically (e.g. in case of special
+conditions).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Named</span>
+<span class="annotation">@SessionScoped</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">PageBean</span>
+{
+ <span class="directive">private</span> <span class="type">int</span> currentValue = -<span class="integer">10</span>;
+
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> NavigationParameterContext navigationParameterContext;
+
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> actionMethod()
+ {
+ currentValue++;
+
+ <span class="keyword">if</span> (currentValue >= <span class="integer">0</span>)
+ {
+ <span class="local-variable">this</span>.navigationParameterContext.addPageParameter(<span class="string"><span class="delimiter">"</span><span class="content">cv</span><span class="delimiter">"</span></span>, <span class="local-variable">this</span>.currentValue);
+ }
+ <span class="keyword">return</span> SimplePageConfig.class;
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_security_integration_via_secured">Security Integration via @Secured</h4>
+<div class="paragraph">
+<p>This annotation is a custom view-meta-data provided by the
+Security-module which allows to integrate 3rd party frameworks (or
+custom approaches) to secure pages as well as whole folders. You can
+annotate specific parts or a marker-interface.
+<code>CustomAccessDecisionVoter</code> used in the following example can be any
+implementation of
+<code>org.apache.deltaspike.security.api.authorization.AccessDecisionVoter</code>
+and needs to be a std. CDI bean which means you can use
+dependecy-injection to trigger any kind of security check. All parts
+which inherit from <code>SecuredPages</code> (<code>Pages.Admin</code>, <code>Pages.Admin.Index</code>
+and <code>Pages.Admin.Home</code>) are protected by <code>CustomAccessDecisionVoter</code>.</p>
+</div>
+<div class="paragraph">
+<p>(It’s easy to check this hierarchy in a modern Java-IDE. Only for
+displaying the final meta-data for every node in the IDE a special
+plug-in would be needed.)</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Secured</span>(CustomAccessDecisionVoter.class)
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">SecuredPages</span> {}
+
+<span class="annotation">@View</span>(navigation = REDIRECT)
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Pages { }
+
+ <span class="type">interface</span> <span class="class">Admin</span> <span class="directive">extends</span> Pages, SecuredPages
+ {
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Admin { }
+
+ <span class="annotation">@View</span>(navigation = FORWARD)
+ <span class="type">class</span> <span class="class">Home</span> <span class="directive">implements</span> Admin { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>For sure it’s also possible to use it without a special interface. In
+this case you would need:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@View</span>(navigation = REDIRECT)
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Pages { }
+
+ <span class="annotation">@Secured</span>(CustomAccessDecisionVoter.class)
+ <span class="type">interface</span> <span class="class">Admin</span> <span class="directive">extends</span> Pages
+ {
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Admin { }
+
+ <span class="annotation">@View</span>(navigation = FORWARD)
+ <span class="type">class</span> <span class="class">Home</span> <span class="directive">implements</span> Admin { }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>or:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@View</span>(navigation = REDIRECT)
+<span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Pages { }
+
+ <span class="type">interface</span> <span class="class">Admin</span> <span class="directive">extends</span> Pages
+ {
+ <span class="annotation">@Secured</span>(CustomAccessDecisionVoter.class)
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Admin { }
+
+ <span class="annotation">@Secured</span>(CustomAccessDecisionVoter.class)
+ <span class="annotation">@View</span>(navigation = FORWARD)
+ <span class="type">class</span> <span class="class">Home</span> <span class="directive">implements</span> Admin { }
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_view_controller_callbacks_via_viewcontrollerref">View-Controller Callbacks via @ViewControllerRef</h4>
+<div class="paragraph">
+<p>This annotation is a custom view-meta-data provided by the JSF-module
+which allows to configure beans which should act as view-controllers.
+That means they can use view-controller callbacks like <code>@InitView</code>,
+<code>@PreViewAction</code>, <code>@PreRenderView</code> and <code>@PostRenderView</code>. The following
+example shows the usage of <code>@PreRenderView</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="comment">//@View //optional</span>
+<span class="annotation">@ViewControllerRef</span>(MyPageController.class)
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyPage</span> <span class="directive">implements</span> ViewConfig
+{
+}
+
+<span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">MyPageController</span>
+{
+ <span class="annotation">@PreRenderView</span>
+ <span class="directive">protected</span> <span class="type">void</span> load()
+ {
+ <span class="comment">//...</span>
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Since v0.7 it’s possible to observe exceptions thrown by a
+@PreRenderView callback and use your configured Default-Error-View to
+display the exception.</p>
+</div>
+<div class="paragraph">
+<p>Example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@ExceptionHandler</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">ErrorViewAwareExceptionHandler</span> {
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> ViewConfigResolver viewConfigResolver;
+
+ <span class="directive">public</span> <span class="type">void</span> onIllegalStateException(<span class="annotation">@Handles</span> ExceptionEvent<<span class="exception">IllegalStateException</span>> e)
+ {
+ FacesContext facesContext = FacesContext.getCurrentInstance();
+
+ <span class="predefined-type">String</span> viewId = viewConfigResolver.getDefaultErrorViewConfigDescriptor().getViewId();
+ UIViewRoot viewRoot = facesContext.getApplication().getViewHandler().createView(facesContext, viewId);
+ facesContext.setViewRoot(viewRoot);
+ <span class="comment">//... - e.g.: store the exception in a page-bean for the default-error-view</span>
+ }
+}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_referencing_views_via_viewref">Referencing Views via @ViewRef</h4>
+<div class="paragraph">
+<p>With <code>@ViewControllerRef#value</code> you can annotate a view-config class to
+bind (/reference) a controller to it. <code>@ViewRef#config</code> allows the same
+in the other direction. Use an existing view-config to reference one or
+many view/s.</p>
+</div>
+<div class="paragraph">
+<p>That means e.g.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> <span class="directive">extends</span> ViewConfig
+{
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> Pages { }
+}
+
+<span class="annotation">@ViewRef</span>(Pages.Index.class)
+<span class="comment">//...</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">IndexController</span> <span class="directive">implements</span> <span class="predefined-type">Serializable</span>
+{
+ <span class="annotation">@PreRenderView</span>
+ <span class="directive">protected</span> <span class="type">void</span> preRenderView()
+ {
+ <span class="comment">//...</span>
+ }
+
+ <span class="comment">//...</span>
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>leads to the invocation of the pre-render-view logic before
+/pages/page1.xhtml gets rendered (and it won’t be called for other
+pages).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_using_the_optional_viewnavigationhandler">Using the (optional) ViewNavigationHandler</h4>
+<div class="paragraph">
+<p>With JSF you typically navigate with the action-method bound to a
+command-component. However, also JSF supports manual navigation via
+<code>javax.faces.application.NavigationHandler</code>. With
+<code>ViewNavigationHandler</code> DeltaSpike provides an equivalent optimized for
+type-safe view-configs which is easier to use (and can be used also for
+other (supported) view technology).</p>
+</div>
+<div class="paragraph">
+<p>A simple example is:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> {
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> ViewConfig { }
+}
+
+<span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">AnyController</span>
+{
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> ViewNavigationHandler viewNavigationHandler;
+
+ <span class="directive">public</span> <span class="type">void</span> anyMethod()
+ {
+ <span class="comment">//navigates to /pages/index.xhtml</span>
+ <span class="local-variable">this</span>.viewNavigationHandler.navigateTo(Pages.Index.class);
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Also in this case (optional) meta-data will be used for the navigation
+process, since <code>ViewNavigationHandler</code> just delegates to the active
+navigation-handler (of JSF).</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_configuring_a_default_error_view">Configuring a Default Error-View</h4>
+<div class="paragraph">
+<p>It’s possible to mark one view-config class as default error-view. That
+means in case of errors it will be used as navigation target
+automatically. Furthermore, it’s also possible to use it in your code
+instead of hardcoding your error-view across the whole application.</p>
+</div>
+<div class="paragraph">
+<p>In case of</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="directive">public</span> <span class="type">interface</span> <span class="class">Pages</span> {
+ <span class="type">class</span> <span class="class">Index</span> <span class="directive">implements</span> ViewConfig { }
+
+ <span class="type">class</span> <span class="class">CustomErrorPage</span> <span class="directive">extends</span> DefaultErrorView { }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>it’s possible to navigate with <code>DefaultErrorView.class</code> instead of
+hardcoding it to <code>Pages.CustomErrorPage.class</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">PageController</span>
+{
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> actionWithoutError()
+ {
+ <span class="keyword">return</span> Pages.Index.class;
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> actionWithError()
+ {
+ <span class="comment">//navigates to the view which is configured as default error-view</span>
+ <span class="keyword">return</span> DefaultErrorView.class;
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you are outside of an action-method you can also use it in
+combination with <code>ViewNavigationHandler</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Model</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">AnyController</span>
+{
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> ViewNavigationHandler viewNavigationHandler;
+
+ <span class="directive">public</span> <span class="type">void</span> anyMethod()
+ {
+ <span class="comment">//navigates to the view which is configured as default error-view</span>
+ <span class="local-variable">this</span>.viewNavigationHandler.navigateTo(DefaultErrorView.class);
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>However, in case of JSF you have to ensure that you are at a valid point
+in the JSF request-lifecycle for a navigation, because invocation gets
+transformed to a std. (implicit) JSF navigation.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_using_matches">Using @Matches</h4>
+<div class="paragraph">
+<p>This annotation is currently not integrated. [TODO]</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_using_viewconfigresolver">Using ViewConfigResolver</h4>
+<div class="paragraph">
+<p>If you would like to query view-meta-data yourself (for whatever
+reason), you can do that with <code>ViewConfigResolver</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@RequestScoped</span>
+<span class="directive">public</span> <span class="type">class</span> <span class="class">ApiDemoBean</span>
+{
+ <span class="annotation">@Inject</span>
+ <span class="directive">private</span> ViewConfigResolver viewConfigResolver;
+
+ <span class="directive">public</span> <span class="predefined-type">String</span> getViewId(<span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> viewConfigClass)
+ {
+ <span class="keyword">return</span> viewConfigResolver.getViewConfigDescriptor(viewConfigClass).getViewId(); <span class="comment">//or #getPath</span>
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">String</span> getPath(<span class="predefined-type">Class</span> pathConfigClass)
+ {
+ <span class="keyword">return</span> viewConfigResolver.getConfigDescriptor(pathConfigClass).getPath();
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">List</span><ConfigDescriptor<?>> getAllFolderDescriptors()
+ {
+ <span class="keyword">return</span> viewConfigResolver.getConfigDescriptors();
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">List</span><ViewConfigDescriptor> getAllPageDescriptors()
+ {
+ <span class="keyword">return</span> viewConfigResolver.getViewConfigDescriptors();
+ }
+
+ <span class="directive">public</span> ViewConfigDescriptor getCurrentViewConfig()
+ {
+ <span class="keyword">return</span> viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId());
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">Class</span><? <span class="directive">extends</span> ViewConfig> getCurrentViewConfigClass()
+ {
+ <span class="keyword">return</span> viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
+ }
+ <span class="comment">//...</span>
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>For folders it’s optional to implement the <code>ViewConfig</code> interface,
+therefore you see 2 different types of API. <code>#getConfigDescriptor</code> as
+the general API and <code>#getViewConfigDescriptor</code> which is specific for
+pages (which have to implement the <code>ViewConfig</code> interface).</p>
+</div>
+<div class="paragraph">
+<p><strong>Besides</strong> translating a config class to the final path of the folder or
+page, it’s possible to get the implicitly as well as explicitly
+configured (view-)meta-data and get and/or execute configured callbacks.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_advanced_api_usages">Advanced API usages</h3>
+<div class="sect3">
+<h4 id="_creating_custom_meta_data_via_viewmetadata">Creating Custom Meta-Data via @ViewMetaData</h4>
+<div class="paragraph">
+<p>This meta-annotation allows to create custom view-meta-data which can be
+used for view-configs. Per default meta-data of a lower level overrides
+meta-data on a higher level which has the same type. That can be
+customized via annotating the final annotation as a whole via
+<code>@Aggregated(true)</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@ViewMetaData</span>
+<span class="annotation">@interface</span> InfoPage
+{
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>By just using <code>@InfoPage</code> in view-configs, it can be queried via:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Inject</span>
+<span class="directive">private</span> ViewConfigResolver viewConfigResolver;
+<span class="comment">//...</span>
+
+ViewConfigDescriptor viewConfigDescriptor = viewConfigResolver.getViewConfigDescriptor(Pages.Index.class);
+<span class="predefined-type">List</span><InfoPage> metaDataList = viewConfigDescriptor.getMetaData(InfoPage.class)</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_creating_custom_meta_data_via_stereotype">Creating Custom Meta-Data via @Stereotype</h4>
+<div class="paragraph">
+<p>Like with CDI itself you can encapsulate multiple view meta-data
+annotation in one annotation.</p>
+</div>
+<div class="paragraph">
+<p>e.g.:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Target</span>({TYPE})
+<span class="annotation">@Retention</span>(RUNTIME)
+
+<span class="annotation">@Stereotype</span>
+<span class="annotation">@Secured</span>(CustomAccessDecisionVoter.class) <span class="comment">//view meta-data #1</span>
+<span class="annotation">@View</span>(navigation = REDIRECT) <span class="comment">//view meta-data #2</span>
+<span class="annotation">@interface</span> MySecuredView {}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Instead of using the same combination of annotations in multiple places,
+you can use the stereotype annotation. If you query the meta-data at
+runtime (see <code>ViewConfigDescriptor#getMetaData</code>), you can access
+<code>@Secured</code> as well as <code>@View</code> (in the example above). however, you won’t
+see <code>@MySecuredView</code> itself at runtime, because stereotype annotations
+are per default transparent.</p>
+</div>
+<div class="paragraph">
+<p>Since v1.0.1+ it’s possible to access such stereotype annotations as
+well, once you annotate them with <code>@ViewMetaData</code>.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_creating_custom_callbacks_via_viewmetadata">Creating Custom Callbacks via @ViewMetaData</h4>
+<div class="paragraph">
+<p>Via a custom ConfigPreProcessor it’s possible to register custom
+callbacks dynamically. The following listing shows a view-config which
+adds a simple callback including the corresponding <code>ConfigPreProcessor</code>
+and <code>ExecutableCallbackDescriptor</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@ViewMetaData</span>(preProcessor = MySecured.AnnotationPreProcessor.class)
+<span class="directive">public</span> <span class="annotation">@interface</span> MySecured
+{
+ <span class="predefined-type">Class</span><? <span class="directive">extends</span> TestAccessDecisionVoter><span class="type">[]</span> value();
+
+ <span class="type">class</span> <span class="class">AnnotationPreProcessor</span> <span class="directive">implements</span> ConfigPreProcessor<MySecured>
+ {
+ <span class="annotation">@Override</span>
+ <span class="directive">public</span> MySecured beforeAddToConfig(MySecured metaData, ViewConfigNode viewConfigNode)
+ {
+ <span class="predefined-type">List</span><CallbackDescriptor> descriptors = viewConfigNode.getCallbackDescriptors(MySecured.class);
+ descriptors.add(<span class="keyword">new</span> <span class="predefined-type">Descriptor</span>(metaData.value(), DefaultCallback.class));
+ <span class="keyword">return</span> metaData;
+ }
+ }
+
+ <span class="directive">static</span> <span class="type">class</span> <span class="class">Descriptor</span> <span class="directive">extends</span> ExecutableCallbackDescriptor<<span class="predefined-type">Set</span><<span class="predefined-type">String</span>>>
+ {
+ <span class="directive">public</span> <span class="predefined-type">Descriptor</span>(<span class="predefined-type">Class</span><span class="type">[]</span> beanClasses, <span class="predefined-type">Class</span><? <span class="directive">extends</span> <span class="predefined-type">Annotation</span>> callbackMarker)
+ {
+ <span class="local-variable">super</span>(beanClasses, callbackMarker);
+ }
+
+ <span class="directive">public</span> <span class="predefined-type">List</span><<span class="predefined-type">Set</span><<span class="predefined-type">String</span>>> execute(<span class="predefined-type">String</span> param1, <span class="predefined-type">String</span> param2)
+ {
+ <span class="keyword">return</span> <span class="local-variable">super</span>.execute(param1, param2);
+ }
+ }
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>By just using <code>@MySecured</code> in view-configs, it can be queried and
+executed via:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="CodeRay highlight"><code data-lang="java"><span class="annotation">@Inject</span>
+<span class="directive">private</span> ViewConfigResolver viewConfigResolver;
+<span class="comment">//...</span>
+ViewConfigDescriptor viewConfigDescriptor = viewConfigResolver.getViewConfigDescriptor(Pages.Secured.Index.class);
+
+<span class="predefined-type">List</span><<span class="predefined-type">Set</span><<span class="predefined-type">String</span>> <span class="comment">/*return type of one callback*/</span>> callbackResult =
+ viewConfigDescriptor.getExecutableCallbackDescriptor(MySecured.class, MySecured.Descriptor.class)
+ .execute(<span class="string"><span class="delimiter">"</span><span class="content">param1</span><span class="delimiter">"</span></span>, <span class="string"><span class="delimiter">"</span><span class="content">param2</span><span class="delimiter">"</span></span>);</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>It’s also possible do register different callback-types per
+view-meta-data. An example can be found at <code>ViewControllerRef</code> which
+registers different callback-types for <code>InitView</code>, <code>PreViewAction</code>,
+<code>PreRenderView</code> and <code>PostRenderView</code>. In this case it’s needed to use
+the type of the callback (= class of the annotation) as additional
+parameter for <code>#getExecutableCallbackDescriptor</code>.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_creating_custom_inline_meta_data_via_inlineviewmetadata">Creating Custom inline Meta-Data via @InlineViewMetaData</h4>
+<div class="paragraph">
+<p>This annotation can be used for view-meta-data which can be placed on
+other classes than view-config-classes. It’s used e.g. for <code>@ViewRef</code>.
+Via a <code>TargetViewConfigProvider</code> it’s possible to point to the
+view-config the meta-data should get applied to and via
+<code>InlineMetaDataTransformer</code> it’s possible to convert it to a different
+meta-data-representation (which allows that at runtime you only have to
+support one side since the inline-meta-data was converted to the same
+meta-data representation which is used for the normal view-meta-data).</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_path_validation">Path-Validation</h3>
+<div class="paragraph">
+<p>DeltaSpike (after v0.5) validates your configs out-of-the-box. The
+application will fail to start, if there is an invalid config (e.g. a
+view-config without a corresponding view). Right now the validation is
+restricted to folders and view-ids with .xhtml or .jsp as suffix. Other
+view-ids (e.g. *.faces) don’t get checked. In such cases a custom
[... 714 lines stripped ...]