<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>