svn commit: r891845 - in /websites/staging/deltaspike/trunk/content: ./ jsf.html

[bu...@apache.org]

Author: buildbot
Date: Thu Dec 26 16:49:49 2013
New Revision: 891845

Log:
Staging update by buildbot for deltaspike

Modified:
    websites/staging/deltaspike/trunk/content/   (props changed)
    websites/staging/deltaspike/trunk/content/jsf.html

Propchange: websites/staging/deltaspike/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Dec 26 16:49:49 2013
@@ -1 +1 @@
-1553394
+1553508

Modified: websites/staging/deltaspike/trunk/content/jsf.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/jsf.html (original)
+++ websites/staging/deltaspike/trunk/content/jsf.html Thu Dec 26 16:49:49 2013
@@ -107,6 +107,7 @@
 <li><a href="#creating-custom-meta-data-via-viewmetadata">Creating Custom Meta-Data via @ViewMetaData</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>
+<li><a href="#path-validation">Path-Validation</a></li>
 </ul>
 </li>
 <li><a href="#view-config-spi">View-Config SPI</a><ul>
@@ -164,6 +165,7 @@ So why should you use something which is
 <ul>
 <li>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).</li>
 <li>It's also easy(er) for tools (IDE plugins,...) to validate it</li>
+<li>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)</li>
 </ul>
 <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>
 <h2 id="basic-api-usages">Basic API usages</h2>
@@ -748,6 +750,10 @@ The following listing shows a view-confi
 <h3 id="creating-custom-inline-meta-data-via-inlineviewmetadata">Creating Custom inline Meta-Data via @InlineViewMetaData</h3>
 <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>
+<h3 id="path-validation">Path-Validation</h3>
+<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 validator can be used (e.g. based on <code>ViewConfigPathValidator</code>).</p>
+<p>To disable the view-config (path) validation, add a <code>ClassDeactivator</code> which restricts <code>org.apache.deltaspike.jsf.impl.config.view.ViewConfigPathValidator</code>.</p>
 <h2 id="view-config-spi">View-Config SPI</h2>
 <p>[TODO]</p>
 <h3 id="configdescriptorvalidator">ConfigDescriptorValidator</h3>