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

[gp...@apache.org]

Author: gpetracek
Date: Sat Mar 30 23:21:35 2013
New Revision: 1462859

URL: http://svn.apache.org/r1462859
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=1462859&r1=1462858&r2=1462859&view=diff
==============================================================================
--- incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext (original)
+++ incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext Sat Mar 30 23:21:35 2013
@@ -35,6 +35,36 @@ Since it's std. Java, you can benefit fr
 
 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.
 
+## Motivation
+
+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:
+It gives a good return in case of real applications (esp. beyond simple demos).
+
+The long answer is:
+
+You can benefit from it from the first second:
+
+ - It's type-safe ->
+     - 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)
+     - you can benefit from the auto.complete features of any modern Java IDE.
+ - 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
+ - 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...)
+ - 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):
+
+ - 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).
+ - It's also easy(er) for tools (IDE plugins,...) to validate it
+
+If you are still not convinced, you just have to try it. You will see how your daily workflow benefits from it pretty soon.
+
 ## Basic API usages
 
 While reading this section keep the following simple rules in mind: