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 <tflem...@flemm-aspire.flem-geo.com> Authored: Sat Feb 18 00:15:28 2017 -0600 Committer: Tim Fleming <tflem...@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 âinverseâ 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 âinverseâ 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).
