| <chapter id="wug.introduction"> |
| <title>Introduction</title> |
| <subtitle>Why use the VoiceTribe Web Toolkit?</subtitle> |
| <sect1> |
| <title>Frameworks, Frameworks Everywhere</title> |
| <para>If you are looking to do web application programming in Java, you |
| have a very large number of choices these days. In fact, there are |
| so many web application frameworks now that it has become somewhat |
| of a joke. One blog site on the Internet poses the question “How |
| many Java web frameworks can you name?” The answer given looks like |
| this:</para> |
| <informaltable frame="none"> |
| <tgroup cols="4" align="left" colsep="0" rowsep="0"> |
| <tbody> |
| <row> |
| <entry>Echo </entry> |
| <entry>Jucas </entry> |
| <entry>Scope </entry> |
| <entry>Cameleon </entry> |
| </row> |
| <row> |
| <entry>Cocoon </entry> |
| <entry>Verge </entry> |
| <entry>Warfare </entry> |
| <entry>JFormular </entry> |
| </row> |
| <row> |
| <entry>Millstone </entry> |
| <entry>Niggle </entry> |
| <entry>JWAA </entry> |
| <entry>Xoplon </entry> |
| </row> |
| <row> |
| <entry>OXF </entry> |
| <entry>Bishop </entry> |
| <entry>Jaffa </entry> |
| <entry>Japple </entry> |
| </row> |
| <row> |
| <entry>Struts </entry> |
| <entry>Barracuda </entry> |
| <entry>Jacquard</entry> |
| <entry>Helma </entry> |
| </row> |
| <row> |
| <entry>SOFIA </entry> |
| <entry>Action Framework</entry> |
| <entry>Macaw </entry> |
| <entry>Dinamica </entry> |
| </row> |
| <row> |
| <entry>Tapestry </entry> |
| <entry>Shocks </entry> |
| <entry>Smile </entry> |
| <entry>WebOnSwing</entry> |
| </row> |
| <row> |
| <entry>WebWork </entry> |
| <entry>TeaServlet </entry> |
| <entry>MyFaces </entry> |
| <entry>Nacho </entry> |
| </row> |
| <row> |
| <entry>RIFE </entry> |
| <entry>wingS </entry> |
| <entry>Chiba </entry> |
| <entry>Cassandra </entry> |
| </row> |
| <row> |
| <entry>Spring MVC</entry> |
| <entry>Expresso </entry> |
| <entry>JBanana </entry> |
| <entry>Genie </entry> |
| </row> |
| <row> |
| <entry>Canyamo </entry> |
| <entry>Bento </entry> |
| <entry>Jeenius </entry> |
| <entry>Melati </entry> |
| </row> |
| <row> |
| <entry>Maverick </entry> |
| <entry>jStatemachine </entry> |
| <entry>JWarp </entry> |
| <entry>Dovetail </entry> |
| </row> |
| <row> |
| <entry>JPublish </entry> |
| <entry>jZonic </entry> |
| <entry>Turbine </entry> |
| <entry>OpenEmcee </entry> |
| </row> |
| <row> |
| <entry>JATO </entry> |
| <entry>Folium </entry> |
| <entry></entry> |
| <entry></entry> |
| </row> |
| </tbody> |
| </tgroup> |
| </informaltable> |
| <para>My own personal list of the more interesting and popular |
| presentation layer frameworks is:</para> |
| <informaltable frame="none"> |
| <tgroup cols="4" align="left" colsep="0" rowsep="0"> |
| <tbody> |
| <row> |
| <entry>JSP/Struts </entry> |
| <entry>Tapestry</entry> |
| <entry>Turbine </entry> |
| <entry>WebWork</entry> |
| </row> |
| <row> |
| <entry>JSF (Java Server Faces)</entry> |
| <entry>Echo </entry> |
| <entry>Freemarker</entry> |
| <entry>TeaServlet</entry> |
| </row> |
| </tbody> |
| </tgroup> |
| </informaltable> |
| </sect1> |
| <sect1> |
| <title>Why "Reinvent the Wheel?"</title> |
| <para>Even given this shorter list, you may be wondering “What good is |
| another web application framework?!” Indeed. Why “re-invent the |
| wheel?” One snappy comeback to that old saw is: <emphasis>because |
| this time we could make it rounder!</emphasis></para> |
| <para>But it was not simply a desire for higher quality that drove the |
| creation of VoiceTribe Web Toolkit (Wicket). Even with so many |
| options, there really is no web toolkit which fills exactly the |
| niche that Wicket fills. In fact, Wicket is quite unlike each of |
| the frameworks above. </para> |
| <para>Wicket’s closest cousins are probably Tapestry and Echo, but even |
| there the likeness is very shallow. Like Tapestry, Wicket uses a |
| special HTML attribute to denote components, enabling easy editing |
| with ordinary HTML editors. Like Echo, Wicket is Swing-like. But |
| Wicket applications are not like applications written in either |
| Tapestry or Echo, because in Wicket you get the best of both |
| worlds. You get the benefits of a Swing-like component model and a |
| non-intrusive approach to HTML. In many situations, this |
| combination may prove to be a significant development |
| advantage.</para> |
| <para>To understand why Wicket is so different, it may help to |
| understand the motivations that created it.</para> |
| <sect2> |
| <title>Motivations</title> |
| <itemizedlist> |
| <listitem> |
| <para><emphasis>Most existing web frameworks provide weak |
| to non-existent support in managing server-side |
| state.</emphasis> This normally means lots of ad-hoc |
| code in web applications dealing with the gory |
| mechanics of state management. While Wicket will not |
| allow you to stop thinking about server state, it goes |
| a long ways towards making it easy and often |
| transparent to manage that state.</para> |
| <para>In Wicket, all server side state is automatically |
| managed. You will never directly use an HttpSession |
| object or similar wrapper to store state. Instead, |
| state is associated with |
| <emphasis>components</emphasis>. Each server-side page |
| component holds a nested hierarchy of stateful |
| components, where each component’s model is a |
| <acronym>POJO</acronym> (Plain Old Java Object). Wicket |
| maintains a map of these pages in each user’s session. |
| One purpose of this page map (and the component |
| hierarchy on each page) is to allow the framework to |
| hide <emphasis>all</emphasis> details of how your |
| components and models are accessed. You deal with |
| simple, familiar Java objects and Wicket deals with |
| things like URLs, session ids and GET/POST requests. |
| You will also find that this well-structured server |
| state makes it very easy to deal with the dreaded "back |
| button problem". In fact, Wicket has a generic and |
| robust solution which can identify and expire |
| browser-cached pages that have become stale due to |
| structural changes to the model of a component on the |
| page. Finally, Wicket has been designed to work with |
| POJO persistence frameworks supporting "detachable |
| objects", such as Hibernate. This can make database |
| driven web applications quite easy to write.</para> |
| <para>For many applications, it will be worth trading off |
| the increased server load of extra server-side state |
| for decreased development costs, lower maintenance |
| costs, quicker time-to-market and generally higher |
| quality software. The basic observation here is that |
| <emphasis>software is expensive and complex while |
| servers from companies like E-machines and Dell are |
| relatively dirt cheap.</emphasis></para> |
| <para>In terms of efficiency versus productivity, perhaps |
| Wicket is to JSP as Java is to C. You can accomplish |
| anything in Wicket in JSP. You may even do it more |
| efficiently in terms of memory or processor |
| consumption. But it may take you weeks or months longer |
| to develop your application. And in the end, since |
| state management in JSP is ad-hoc, you are likely find |
| security problems and bugs popping up everywhere. Most |
| of the other frameworks above will do only a little |
| more to help you.</para> |
| </listitem> |
| <listitem> |
| <para><emphasis>Most existing frameworks require special |
| HTML code.</emphasis> JSP is by far the worst offender, |
| allowing the embedding of Java code directly in web |
| pages, but to some degree <emphasis>almost</emphasis> |
| all of the frameworks from the list (except Tapestry) |
| above introduce some kind of special syntax to your |
| HTML code.</para> |
| <para>Special syntax is highly undesirable because it |
| <emphasis>changes the nature of HTML</emphasis> from |
| the kind of pure-and-simple HTML markup that web |
| designers are familiar with, to some kind of |
| <emphasis>special HTML</emphasis>. This special HTML |
| can be more difficult to preview, edit and |
| understand.</para> |
| <para>Wicket does not introduce any special syntax to HTML. |
| This means that you can use Macromedia Dreamweaver, |
| Microsoft Front Page, Word, Adobe Go Live, or any other |
| existing HTML editor to work on your web pages and web |
| components. To accomplish this, Wicket consistently |
| uses a single <emphasis>component name |
| attribute</emphasis> (the name of which you can choose) |
| to mark HTML tags that should receive special treatment |
| by the toolkit.</para> |
| <para>No “special sauce” in your HTML means designers can |
| mock up pages <emphasis>that you can use directly in |
| development.</emphasis> Adding Java components to the |
| HTML is as simple as setting the component name |
| attribute. And you can then give the HTML back to your |
| web designers knowing that they can change it with |
| confidence. Wicket, more than any other framework gives |
| you a <emphasis>separation of concerns.</emphasis> Web |
| designers can work on the HTML with very little |
| knowledge of the application code (they cannot remove |
| the component name tags and they cannot arbitrarily |
| change the nesting of components, but |
| <emphasis>anything else goes</emphasis>). Likewise, |
| coders can work on the Java components that attach to |
| the HTML without concerning themselves with what a |
| given page looks like. By not stepping on each other’s |
| toes, everyone can get more work done.</para> |
| </listitem> |
| <listitem> |
| <para><emphasis>Existing frameworks are not easy or |
| Swing-like.</emphasis> Most of the existing toolkits |
| have a poorly defined or non-existent object model. In |
| some cases, the model is defined using special XML |
| syntaxes. The syntaxes may be so cumbersome that |
| special tools are required to manipulate all the |
| configuration information. Since these toolkits are not |
| simple Java libraries you may or may not be able to use |
| your favorite IDE tools such as editors, debuggers and |
| compilers.</para> |
| <para>Wicket believes in simplicity. There are no |
| configuration files to learn in Wicket. Wicket is a |
| simple class library with a consistent approach to |
| component structure. In Wicket, your web applications |
| will more closely resemble a Swing application than a |
| JSP application. If you know Java (and especially if |
| you know Swing), you already know a lot about |
| Wicket.</para> |
| </listitem> |
| <listitem> |
| <para><emphasis>Existing frameworks inhibit |
| reusability.</emphasis> Even Tapestry and JSF (which at |
| least have component models) do not make it trivial to |
| build and package components to be reused as modules. |
| Wicket has been explicitly designed to make it easy to |
| create reusable components. It’s surprisingly simple to |
| make compound components such as a "SignInPanel" or |
| "AddressForm". It is also relatively easy to create |
| components that exploit new features of browsers. |
| Components can be packaged up in JAR files and reused |
| by simply dropping them in your lib folder – no |
| configuration necessary!</para> |
| </listitem> |
| <listitem> |
| <para><emphasis>Web programming should be fun!</emphasis> |
| This is my most personal goal for writing Wicket. None |
| of the existing frameworks are appealing to me in terms |
| of intuitiveness, quickness, ease of development, etc. |
| It is my hope that Wicket represents a significant step |
| in the direction of making web applications easy and |
| fun to write.</para> |
| </listitem> |
| </itemizedlist> |
| </sect2> |
| <sect2> |
| <title>Goals</title> |
| <para>Coming from these motivations, the following goals for Wicket |
| emerged:</para> |
| <variablelist> |
| <varlistentry> |
| <term> |
| <emphasis>easy (simple / consistent / |
| obvious)</emphasis> |
| </term> |
| <listitem> |
| <itemizedlist> |
| <listitem> |
| <para>POJO-centric </para> |
| </listitem> |
| <listitem> |
| <para>All code written in Java ala Swing </para> |
| </listitem> |
| <listitem> |
| <para>Minimize "conceptual surface area" </para> |
| </listitem> |
| <listitem> |
| <para>Avoid overuse of XML configuration files |
| </para> |
| </listitem> |
| <listitem> |
| <para>Fully solve “back button problem” </para> |
| </listitem> |
| <listitem> |
| <para>Easy to create bookmarkable pages </para> |
| </listitem> |
| <listitem> |
| <para>Hibernate integration for easy database |
| persistence </para> |
| </listitem> |
| <listitem> |
| <para>Maximum type safety and compile-time |
| problem diagnosis</para> |
| </listitem> |
| <listitem> |
| <para>Maximum diagnosis of run-time problems |
| </para> |
| </listitem> |
| <listitem> |
| <para>Minimum reliance on special tools </para> |
| </listitem> |
| <listitem> |
| <para>Components, containers and conventions |
| should be consistent</para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term> |
| <emphasis>reusable</emphasis> |
| </term> |
| <listitem> |
| <itemizedlist> |
| <listitem> |
| <para>Components written in Wicket should be |
| fully reusable</para> |
| </listitem> |
| <listitem> |
| <para>Reusable components should be easily |
| distributed in ordinary JAR files</para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term> |
| <emphasis>non-intrusive</emphasis> |
| </term> |
| <listitem> |
| <itemizedlist> |
| <listitem> |
| <para>HTML or other markup not polluted with |
| programming semantics </para> |
| </listitem> |
| <listitem> |
| <para>Only one simple tagging construct in |
| markup </para> |
| </listitem> |
| <listitem> |
| <para>Compatible with any ordinary HTML editor |
| </para> |
| </listitem> |
| <listitem> |
| <para>Easy for graphics designers to recognize |
| and avoid framework tagging</para> |
| </listitem> |
| <listitem> |
| <para>Easy to add tagging back to HTML if |
| designers accidentally remove it</para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term> |
| <emphasis>safe</emphasis> |
| </term> |
| <listitem> |
| <itemizedlist> |
| <listitem> |
| <para>Code is secure by default </para> |
| </listitem> |
| <listitem> |
| <para>Only explicitly created external page |
| links can expose state in the page or in |
| the URL</para> |
| </listitem> |
| <listitem> |
| <para>All logic in Java with maximum type |
| safety </para> |
| </listitem> |
| <listitem> |
| <para>Easy to integrate with Java security |
| </para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| </varlistentry> |
| <varlistentry> |
| <term> |
| <emphasis>efficient / scalable</emphasis> |
| </term> |
| <listitem> |
| <itemizedlist> |
| <listitem> |
| <para>Efficient and lightweight, but not at the |
| expense of other goals</para> |
| </listitem> |
| <listitem> |
| <para>Use of “sticky sessions” can achieve |
| scalability (without failover)</para> |
| </listitem> |
| <listitem> |
| <para>Clustering via session replication more |
| heavyweight, but possible</para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| </sect2> |
| </sect1> |
| <sect1> |
| <title>Performance</title> |
| <para>Although Wicket is a very convenient, efficient and powerful way |
| to code a web application, it almost certainly will consume more |
| server side resources (memory in particular) than most existing |
| frameworks, including JSP, Tapestry and JSF. In other words, the |
| benefits of Wicket are not achieved without a price. </para> |
| <para>Since no significant applications have yet been written in |
| Wicket, performance characteristics of the toolkit are not yet well |
| understood and it is expected that Wicket may not be appropriate |
| for web applications which require especially high performance |
| and/or which must be highly <emphasis>available.</emphasis></para> |
| <para>If you are unsure whether your application will scale in Wicket, |
| it would be advisable to write a simple mockup that will simulate |
| the kind of load you might expect. This can at least give you a |
| ballpark for how much memory Wicket is going to consume with its |
| additional server side state. </para> |
| <para>Pages in the Wicket examples appear to consume something on the |
| order of 5-20KB of memory per page. With a limit of 10 pages per |
| session, session would consume as much as 200KB. This would |
| translate to roughly 5 user sessions per MB. Therefore, on a system |
| with 256MB of RAM free for user sessions, the system would be able |
| to support about 1,280 users. This seems like a lot but remember |
| that many of these sessions at any given time will be abandoned and |
| awaiting expiration. While pages having more complex component |
| structures will consume more memory, your average user isn’t going |
| to view 10 pages. As you can see, the variables involved are very |
| complex and application-dependent. Given this, the best thing is to |
| do if you are unsure of yourself is to create a simple mockup and |
| do some load testing.</para> |
| </sect1> |
| <sect1> |
| <title>Clustering and Scalability / Availability</title> |
| <para>If high levels of scalability or availability (or both) are |
| required, you may wish to <emphasis>cluster</emphasis> your web |
| application. A clustered application runs fairly transparently on |
| many servers at once. </para> |
| <para>Wicket 1.0 does not yet provide direct support for clustering, |
| although it is anticipated that such support will be added in the |
| future. Generally speaking, good scalability can be achieved |
| through load balancing via “sticky sessions”, while failover cannot |
| currently be achieved at all. Adding full-featured clustering in |
| the future should not be an insurmountable task. It would be fairly |
| straightforward right now to serialize session properties and pages |
| to failover server(s). But doing this efficiently and correctly is |
| beyond the scope of the initial release of Wicket. It is hoped that |
| someone with real clustering knowledge and experience will step |
| forward and help the Wicket project out in version 1.1.</para> |
| </sect1> |
| <sect1> |
| <title>The Future of Wicket</title> |
| <para>Wicket is an open source project, and as such the future of |
| Wicket depends on people exactly like you. The reader is encouraged |
| to participate in the Wicket community. Whether you answer or ask |
| questions or write source code, the Wicket community will |
| determine, to a large exent, where Wicket will go in the future. |
| </para> |
| <para>I plan to be active in the Wicket community and a steward of the |
| open source project. This book and the associated plug-in CD will |
| be distributed on-line and together these will be the sole sources |
| of compensation that I will receive for months of hard work |
| creating the now open source Wicket core. Your purchase of this |
| book is an important contribution to the Wicket community and will |
| help to enable me to pitch in and make Wicket better in the future. |
| Thank-you!!</para> |
| </sect1> |
| <sect1> |
| <title>How to Read This Book</title> |
| <para>This book is example driven and most chapters discuss the |
| examples included in the Wicket SDK blow by blow. However, this is |
| done by breaking the examples into bite-size fragments which are |
| inserted in appropriate places in the discussion. To save on paper, |
| comments are removed in most cases and the full source code for |
| each example is not printed anywhere in this guide. It is suggested |
| that you will want to view the full source code in your favorite |
| IDE, where you can follow along as you read.</para> |
| </sect1> |
| </chapter> |
