deltaspike-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1462859 - /incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext
Date Sat, 30 Mar 2013 23:21:35 GMT
Author: gpetracek
Date: Sat Mar 30 23:21:35 2013
New Revision: 1462859

updated content


Modified: incubator/deltaspike/site/trunk/content/deltaspike/jsf.mdtext
--- 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
+## 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
+ - 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:

View raw message