svn commit: r1462861 - /incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext

[gp...@apache.org]

Author: gpetracek
Date: Sat Mar 30 23:28:58 2013
New Revision: 1462861

URL: http://svn.apache.org/r1462861
Log:
updated content

Modified:
    incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext

Modified: incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext
URL: http://svn.apache.org/viewvc/incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext?rev=1462861&r1=1462860&r2=1462861&view=diff
==============================================================================
--- incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext (original)
+++ incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext Sat Mar 30 23:28:58 2013
@@ -40,10 +40,11 @@ Even the concepts provided by modules (o
 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 **initially**?
 
-The short answer is:
+**The short answer is:**
+
 It gives a good return in case of real applications (esp. beyond simple demos).
 
-The long answer is:
+**The long answer is:**
 
 You can benefit from it from the first second:
 
@@ -53,9 +54,10 @@ You can benefit from it from the first s
  - 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
  - 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)
  - You can configure meta-data in a central place (which can get inherited via **multiple** inheritance based on Java interfaces)
- - Easier for new developers to find usages
+ - Easier for developers to find usages
  - Allows easy(er) refactorings and maintenance
- - 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...)
+ - 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...)
  - 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.
 
 Advantages which are planned for later (= currently not supported):
@@ -166,7 +168,7 @@ Furthermore, inheritance can be used to 
 ### Navigation Parameters
 
 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. `@View#navigation` and `@View#viewParams`). Instead of adding `faces-redirect=true` manually it's done for you as soon as you are using `@View(navigation = REDIRECT)`. The same goes for `includeViewParams=true` and `@View(viewParams = INCLUDE)`.
+It isn't needed to add all (types of) parameters that way. Some get added autom. based on special meta-data (e.g. `@View#navigation` and `@View#viewParams`). Instead of adding `"faces-redirect=true"` manually it's done for you as soon as you are using `@View(navigation = REDIRECT)`. The same goes for `"includeViewParams=true"` and `@View(viewParams = INCLUDE)`.
 
 #### Static Configuration via @NavigationParameter
 In some cases it's needed to add an information in any case. So you can annotate the view-config class with `@NavigationParameter`. Supported values are static strings or EL-expressions.