You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by sv...@apache.org on 2017/02/18 10:11:26 UTC
[1/2] wicket git commit: Minor fixes to guide documentation
Repository: wicket
Updated Branches:
refs/heads/master 05a174130 -> da071f7a6
Minor fixes to guide documentation
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/77602c0d
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/77602c0d
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/77602c0d
Branch: refs/heads/master
Commit: 77602c0deba29966e17beba8451de6046e5e6acc
Parents: 05a1741
Author: Tim Fleming <tf...@flemm-aspire.flem-geo.com>
Authored: Sat Feb 18 00:15:28 2017 -0600
Committer: Tim Fleming <tf...@flemm-aspire.flem-geo.com>
Committed: Sat Feb 18 00:15:28 2017 -0600
----------------------------------------------------------------------
wicket-user-guide/src/main/asciidoc/contributing.adoc | 4 ++--
wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc | 6 +++---
wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc | 6 +++---
wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc | 4 ++--
wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/wicket/blob/77602c0d/wicket-user-guide/src/main/asciidoc/contributing.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/contributing.adoc b/wicket-user-guide/src/main/asciidoc/contributing.adoc
index 61c220b..fab207f 100644
--- a/wicket-user-guide/src/main/asciidoc/contributing.adoc
+++ b/wicket-user-guide/src/main/asciidoc/contributing.adoc
@@ -13,13 +13,13 @@ git clone https://github.com/apache/wicket.git
* To preview your changes run _mvn clean package -P guide_ in the `wicket/wicket-user-guide` folder (in eclipse use a run configuration)
-* Navigate to _wicket/wicket-user-guide/target/guide/8.x_ and open one of the following files a browser / pdf viewer:
+* Navigate to _wicket/wicket-user-guide/target/guide/8.x_ and open one of the following files in a browser / pdf viewer:
** _guide/single.html_ (single page version)
** _guide/single.pdf_ (single page pdf version)
* Create a ticket in Apache Wicket's https://issues.apache.org/jira/browse/WICKET[JIRA]
-* *Commit and push the changes* to your forked Apacke Wicket's GIT repository and *create a pull request* on github
+* *Commit and push the changes* to your forked Apache Wicket's GIT repository and *create a pull request* on github
*Thank you!*
http://git-wip-us.apache.org/repos/asf/wicket/blob/77602c0d/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc
index 1922670..54f33c9 100644
--- a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc
+++ b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_1.adoc
@@ -1,10 +1,10 @@
...but we all hate spaghetti code! That's why in the first half of the 2000s we have seen the birth of so many web frameworks. Their mission was to separate our business code from presentation layer (like JSP pages).
-Some of theme (like Struts, Spring MVC, Velocity, etc...) have become widely adopted and they made the MVC pattern very popular among developers.
-However, none of these frameworks offers a real object-oriented (OO) abstraction for web pages and we still have to take care of web-related tasks such as HTTP request/response handling, URLs mapping, storing data into user session and so on.
+Some of them (like Struts, Spring MVC, Velocity, etc...) have become widely adopted and they made the MVC pattern very popular among developers.
+However, none of these frameworks offers a real object-oriented (OO) abstraction for web pages and we still have to take care of web-related tasks such as HTTP request/response handling, URL mapping, storing data into user sessions and so on.
-The biggest limit of MVC frameworks is that they don't do much to overcome the impedance mismatch between the stateless nature of HTTP protocol and the need of our web applications of handling a (very complex) state.
+The biggest limit of MVC frameworks is that they don't do much to overcome the impedance mismatch between the stateless nature of HTTP protocol and the need for our web applications to handle (a very complex) state.
To overcome these limits developers have started to adopt a new generation of component oriented web frameworks designed to provide a completely different approach to web development.
http://git-wip-us.apache.org/repos/asf/wicket/blob/77602c0d/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc
index 62c908f..b1a95f6 100644
--- a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc
+++ b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_2.adoc
@@ -1,8 +1,8 @@
-Component oriented frameworks differ from classic web frameworks in that they build a model of requested page on the server side and the HTML sent back to the client is generated according to this model. You can think of the model as if it was an \u201cinverse\u201d JavaScript DOM, meaning that:
+Component oriented frameworks differ from classic web frameworks in that they build a model of requested pages on the server side and the HTML sent back to the client is generated according to this model. You can think of the model as if it was an \u201cinverse\u201d JavaScript DOM, meaning that:
-1. is built on server-side
-2. is built before HTML is sent to client
+1. it is built on the server-side
+2. it is built before HTML is sent to the client
3. HTML code is generated using this model and not vice versa.
image::../img/requesthandling-general.png[]
http://git-wip-us.apache.org/repos/asf/wicket/blob/77602c0d/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc
index 5e69458..5a198ff 100644
--- a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc
+++ b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_3.adoc
@@ -1,9 +1,9 @@
-At this point some people may still wonder why OOP is so important also for web development and what benefits it can bring to developers.
+At this point some people may still wonder why OOP is so important for web development and what benefits it can bring to developers.
Let's quickly review the main advantages that this paradigm can offer us:
* *Web pages are objects*: web pages are not just text files sent back to the client. They are object instances and we can harness OOP to design web pages and their components. With Wicket we can also apply inheritance to HTML markup in order to build a consistent graphic layout for our applications (we will see markup inheritance in <<layout.adoc#_here_comes_the_inheritance,chapter 4.2>>).
-* *We don't have to worry about application's state*: pages and components can be considered stateful entities. They are Java objects and they can keep a state inside them and reference other objects. We can stop worrying about keeping track of user data stored inside the _HttpSession_ and we can start managing them in a natural and transparent way.
+* *We don't have to worry about an application's state*: pages and components can be considered stateful entities. They are Java objects and they can keep a state inside them and reference other objects. We can stop worrying about keeping track of user data stored inside the _HttpSession_ and we can start managing them in a natural and transparent way.
* *Testing web applications is much easier*: since pages and components are pure objects, you can use JUnit to test their behavior and to ensure that they render as expected. Wicket has a set of utility classes for unit testing that simulate user interaction with web pages, hence we can write acceptance tests using just JUnit without any other test framework (unit testing is covered in
<<_test_driven_development_with_wicket,chapter 23>>).
http://git-wip-us.apache.org/repos/asf/wicket/blob/77602c0d/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc
index e27362b..d46846a 100644
--- a/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc
+++ b/wicket-user-guide/src/main/asciidoc/whyLearn/whyLearn_4.adoc
@@ -7,7 +7,7 @@ Wicket is not the only component oriented framework available in the Java ecosys
* *Wicket is just about Java and good old HTML*: almost all web frameworks force users to adopt special tags or to use server side code inside HTML markup. This is clearly in contrast with the concept of separation between presentation and business logic and it leads to a more confusing code in our pages. In Wicket we don't have to take care of generating HTML inside the page itself, and we won't need to use any tag other than standard HTML tags. All we have to do is to attach our components (Java instances) to the HTML tags using a simple tag attribute called _wicket:id_ (we will shortly see how to use it).
-* *With Wicket we can easily use JavaBeans and http://en.wikipedia.org/wiki/Plain_Old_Java_Object[POJO] in our web tier*: one of the most annoying and error-prone task in web development is collecting user input through a form and keeping form fields updated with previously inserted values. This usually requires a huge amount of code to extract input from request parameters (which are strings), parse them to Java types and store them into some kind of variable. And this is just half of the work we have to do as we must implement the inverse path (load data from Java to the web form).Moreover, most of the times our forms will use a JavaBean or a POJO as backing object, meaning that we must manually map form fields with the corresponding object fields and vice versa. Wicket comes with an intuitive and flexible mechanism that does this mapping for us without any configuration overhead (using a convention over configuration approach) and in a transparent way.
-<<_wicket_models_and_forms,Chapter 10>> will introduce the concept of Wicket model and we will learn how to harness this entity with forms.
+* *With Wicket we can easily use JavaBeans and http://en.wikipedia.org/wiki/Plain_Old_Java_Object[POJO] in our web tier*: one of the most annoying and error-prone tasks in web development is collecting user input through a form and keeping form fields updated with previously inserted values. This usually requires a huge amount of code to extract input from request parameters (which are strings), parse them to Java types and store them into some kind of variable. And this is just half of the work we have to do as we must implement the inverse path (load data from Java to the web form). Moreover, most times our forms will use a JavaBean or a POJO as a backing object, meaning that we must manually map form fields with the corresponding object fields and vice versa. Wicket comes with an intuitive and flexible mechanism that does this mapping for us without any configuration overhead (using a convention over configuration approach) and in a transparent way.
+<<_wicket_models_and_forms,Chapter 10>> will introduce a Wicket model concept and we will learn how to harness this entity with forms.
* *No complex XML needed*: Wicket was designed to minimize the amount of configuration files needed to run our applications. No XML file is required except for the standard deployment descriptor web.xml (unless you are using Servlet 3 or a later version. See <<whyLearn.adoc#_component_oriented_frameworks_an_overview,Chapter 4>> for more details).
[2/2] wicket git commit: Minor guide fixes
Posted by sv...@apache.org.
Minor guide fixes
This closes #213
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/da071f7a
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/da071f7a
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/da071f7a
Branch: refs/heads/master
Commit: da071f7a6294bbedbb6848f6dd19232eee534e97
Parents: 77602c0
Author: Tim Fleming <tf...@flemm-aspire.flem-geo.com>
Authored: Sat Feb 18 02:01:48 2017 -0600
Committer: Sven Meier <sv...@apache.org>
Committed: Sat Feb 18 11:10:28 2017 +0100
----------------------------------------------------------------------
.../src/main/asciidoc/helloWorld/helloWorld_2.adoc | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/wicket/blob/da071f7a/wicket-user-guide/src/main/asciidoc/helloWorld/helloWorld_2.adoc
----------------------------------------------------------------------
diff --git a/wicket-user-guide/src/main/asciidoc/helloWorld/helloWorld_2.adoc b/wicket-user-guide/src/main/asciidoc/helloWorld/helloWorld_2.adoc
index 45e5226..ade0c59 100644
--- a/wicket-user-guide/src/main/asciidoc/helloWorld/helloWorld_2.adoc
+++ b/wicket-user-guide/src/main/asciidoc/helloWorld/helloWorld_2.adoc
@@ -1,5 +1,5 @@
-In this chapter we will see a classic Hello World! example implemented using a Wicket page with a built-in component called _Label_ (the code is from project the HelloWorldExample). Since this is the first example of the guide, before looking at Java code we will go through the common artifacts needed to build a Wicket application from scratch.
+In this chapter we will see a classic Hello World! example implemented using a Wicket page with a built-in component called _Label_ (the code is from the HelloWorldExample project). Since this is the first example of the guide, before looking at Java code we will go through the common artifacts needed to build a Wicket application from scratch.
NOTE: All the example projects presented in this document have been generated using Maven and the utility page at http://wicket.apache.org/start/quickstart.html[http://wicket.apache.org/start/quickstart.html] . *Appendix A* contains the instructions needed to use these projects and build a quickstart application using Apache Maven. All the artifacts used in the next example (files web.xml, HomePage.class and HomePage.html) are automatically generated by Maven.
@@ -60,7 +60,7 @@ Class _Application_ comes with a set of configuration methods that we can overri
public abstract Class<? extends Page> getHomePage()
----
-As you may guess from its name, this method specifies which page to use as homepage for our application.
+As you may guess from its name, this method specifies which page to use as a homepage for our application.
Another important method is _init()_:
[source,java]
@@ -68,9 +68,9 @@ Another important method is _init()_:
protected void init()
----
-This method is called when our application is loaded by the web server (Tomcat, Jetty, etc...) and is the ideal place to put our configuration code. The _Application_ class exposes its settings grouping them into interfaces (you can find them in package _org.apache.wicket.settings_). We can access these interfaces through getter methods that will be gradually introduced in the next chapters when we will cover the related settings.
+This method is called when our application is loaded by the web server (Tomcat, Jetty, etc...) and is the ideal place to put our configuration code. The _Application_ class exposes its settings grouping them into interfaces (you can find them in package _org.apache.wicket.settings_). We can access these interfaces through getter methods, which will be gradually introduced in the next chapters when covering related settings.
-The current application's instance can be retrieved at any time calling static method _Application.get()_ in our code. We will give more details about this method in <<requestProcessing.adoc#_the_director_of_request_processing_requestcycle,chapter 9.3>>. The content of the application class from project HelloWorldExample is the following:
+The current application's instance can be retrieved at any time by calling static method _Application.get()_ in our code. We will give more details about this method in <<requestProcessing.adoc#_the_director_of_request_processing_requestcycle,chapter 9.3>>. The content of the application class from the HelloWorldExample project is the following:
[source,java]
----
@@ -91,8 +91,8 @@ public class WicketApplication extends WebApplication
}
----
-Since this is a very basic example of a Wicket application, we don't need to specify anything inside the _init_ method. The home page of the application is the _HomePage_ class. In the next paragraph we will see how this page is implemented and which conventions we have to follow to create a page in Wicket.
+Since this is a very basic example of a Wicket application, we don't need to specify anything inside the _init_ method. The home page of the application is the _HomePage_ class. In the next paragraph we will see how this page is implemented and what conventions we have to follow to create a page in Wicket.
-NOTE: Declaring a _WicketFilter_ inside web.xml descriptor is not the only way we have to kickstart our application.
+NOTE: Declaring a _WicketFilter_ inside web.xml descriptor is not the only way we have to kick-start our application.
If we prefer to use a servlet instead of a filter, we can use class _org.apache.wicket.protocol.http.WicketServlet_. See the JavaDoc for further details.