You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by hl...@apache.org on 2008/07/19 19:33:23 UTC

svn commit: r678187 - in /tapestry/tapestry5/trunk: src/site/ src/site/apt/ src/site/apt/cookbook/ src/site/apt/dev/ src/site/fml/faq/ tapestry-core/src/site/ tapestry-core/src/site/apt/ tapestry-ioc/src/site/ tapestry-ioc/src/site/apt/

Author: hlship
Date: Sat Jul 19 10:33:22 2008
New Revision: 678187

URL: http://svn.apache.org/viewvc?rev=678187&view=rev
Log:
TAPESTRY-2480: Migrate Tapestry "what's new?" and upgrade information up to the project level

Added:
    tapestry/tapestry5/trunk/src/site/apt/cookbook/
    tapestry/tapestry5/trunk/src/site/apt/cookbook/defaultparameter.apt
    tapestry/tapestry5/trunk/src/site/apt/cookbook/index.apt
    tapestry/tapestry5/trunk/src/site/apt/cookbook/informals.apt
    tapestry/tapestry5/trunk/src/site/apt/upgrade.apt
      - copied, changed from r673794, tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade.apt
    tapestry/tapestry5/trunk/src/site/apt/upgrade4.apt
      - copied unchanged from r673794, tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade4.apt
Removed:
    tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade4.apt
    tapestry/tapestry5/trunk/tapestry-ioc/src/site/apt/upgrade.apt
Modified:
    tapestry/tapestry5/trunk/src/site/apt/dev/env.apt
    tapestry/tapestry5/trunk/src/site/fml/faq/general.fml
    tapestry/tapestry5/trunk/src/site/site.xml
    tapestry/tapestry5/trunk/tapestry-core/src/site/site.xml
    tapestry/tapestry5/trunk/tapestry-ioc/src/site/site.xml

Added: tapestry/tapestry5/trunk/src/site/apt/cookbook/defaultparameter.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/cookbook/defaultparameter.apt?rev=678187&view=auto
==============================================================================
--- tapestry/tapestry5/trunk/src/site/apt/cookbook/defaultparameter.apt (added)
+++ tapestry/tapestry5/trunk/src/site/apt/cookbook/defaultparameter.apt Sat Jul 19 10:33:22 2008
@@ -0,0 +1,52 @@
+ ---
+ Default Parameter
+ ---
+
+Default Parameter
+
+ Many of components provided with Tapestry share a common behavior:  if the component's
+ id matches a property of the container, then some parameter of the component (usually <<<value>>>)
+ defaults to that property.
+
+ This is desirable, in terms of not having to specify the component's id and then specify the
+ same value as some other parameter.
+
+ Making this work involves two concepts: default parameter methods (methods that can
+ compute a default value for a parameter), and
+ a service,
+ {{{../apidocs/org/apache/tapestry5/services/ComponentDefaultProvider.html}ComponentDefaultProvider}}.
+
+ Let's say you have a component, OutputGadget, whose job is to output some information about
+ an entity type, Gadget.
+
+---
+public class OutputGadget
+{
+  @Parameter(required=true, principal=true)
+  private Gadget gadget;
+
+  @Inject
+  private ComponentDefaultProvider defaultProvider;
+
+  @Inject
+  private ComponentResources resources;
+
+  Binding defaultGadget()
+  {
+    return defaultProvider.defaultBinding("gadget", resources);
+  }
+}
+---
+
+  This can now be used as \<t:outputgadget t:id="currentGadget"/\>, assuming currentGadget is a property
+  of the container.
+
+  If there is no matching property, then the defaultGadget() method will return null, and a runtime exception
+  will be thrown because the gadget parameter is required and not bound.
+
+  The principal attribute on the Parameter annotation is not needed in the specific case; in some cases,
+  a default for some other parameter may be based on the bound type of another parameter, the principal
+  attribute forces the paarameter to be resolved first.  In many Tapestry form components, the value
+  parameter is principal, so that the validate and translate parameters can computer
+  defaults, based on the
+  type and annotations bound to the value parameter.
\ No newline at end of file

Added: tapestry/tapestry5/trunk/src/site/apt/cookbook/index.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/cookbook/index.apt?rev=678187&view=auto
==============================================================================
--- tapestry/tapestry5/trunk/src/site/apt/cookbook/index.apt (added)
+++ tapestry/tapestry5/trunk/src/site/apt/cookbook/index.apt Sat Jul 19 10:33:22 2008
@@ -0,0 +1,6 @@
+ ----
+ Tapestry 5 Cookbook
+ ----
+
+  The Tapestry Cookbook is a collection of tips and tricks for commonly occuring
+  patterns in Tapestry.

Added: tapestry/tapestry5/trunk/src/site/apt/cookbook/informals.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/cookbook/informals.apt?rev=678187&view=auto
==============================================================================
--- tapestry/tapestry5/trunk/src/site/apt/cookbook/informals.apt (added)
+++ tapestry/tapestry5/trunk/src/site/apt/cookbook/informals.apt Sat Jul 19 10:33:22 2008
@@ -0,0 +1,91 @@
+ ----
+ Supporting Informal Parameters
+ ----
+ 
+Supporting Informal Parameters
+
+  Informal parameters are additional parameters beyond the formal parameters
+  defined for a component using the
+  {{{../apidocs/org/apache/tapestry5/annotations/Parameter.html}Parameter}}
+  annotation.
+
+  A component that closely emulates a particular HTML element should also
+  support informal parameters.  You'll find that many of the built-in
+  Tapestry components, such as Form, Label and TextField, do exactly that.
+
+  Normally, specifying additional parameters for a component, beyond its
+  formal parameters, does nothing: the additional parameters are ignored.
+
+  The
+  {{{../apidocs/org/apache/tapestry5/annotations/SupportsInformalParameters.html}SupportsInformalParameters}}
+  annotation is used to identify a component for which informal parameters
+  are to be kept.
+
+  The example is an Img component, a replacement for the \<img\> tag.
+  Its src parameter will be an asset.
+
+----
+@SupportsInformalParameters
+public class Img
+{
+  @Parameter(required=true, allowNull=false, defaultPrefix=BindingConstants.ASSET)
+  private Asset src;
+
+  @Inject
+  private ComponentResources resources;
+
+  boolean beginRender(MarkupWriter writer)
+  {
+     writer.element("img",
+                    "src", src);
+
+     resources.renderInformalParameters(writer);
+
+     writer.end();
+
+     return false;
+  }
+}
+----
+
+  The call to renderInformalParameters() is what converts and outputs
+  the informal parameters. It should occur <after> your code has
+  rendered attributes into the element (earlier written attributes
+  will <not> be overwritten by later written attributes).
+
+  Returning false from beginRender() ensures that the body of the component
+  is not rendered, which makes sense for a \<img\> tag, which has no body.
+
+  Another option is to use the
+  {{{../apidocs/org/apache/tapestry5/corelib/mixins/RenderInformals.html}RenderInformals}}
+  mixin:
+
+----
+public class Img
+{
+  @Parameter(required=true, allowNull=false, defaultPrefix=BindingConstants.ASSET)
+  private Asset src;
+
+  @Mixin
+  private RenderInformals renderInformals;
+
+  void beginRender(MarkupWriter writer)
+  {
+     writer.element("img",
+                    "src", src);
+
+     resources.renderInformalParameters(writer);
+  }
+
+  boolean beforeRenderBody(MarkupWriter writer)
+  {
+    writer.end();
+
+    return false;
+  }
+}
+----
+
+  This variation splits the rendering of the tag in two pieces, so that
+  the RenderInformals mixin can operate (after beginRender() and before
+  beforeRenderBody()).
\ No newline at end of file

Modified: tapestry/tapestry5/trunk/src/site/apt/dev/env.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/dev/env.apt?rev=678187&r1=678186&r2=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/src/site/apt/dev/env.apt (original)
+++ tapestry/tapestry5/trunk/src/site/apt/dev/env.apt Sat Jul 19 10:33:22 2008
@@ -8,7 +8,7 @@
   
   Effectively, you should have the following tools:
   
-  * Maven 2.0.8
+  * Maven 2.0.9
   
   * Ant 1.7.0
   
@@ -16,7 +16,7 @@
 
   []
 
-  IntelliJ is available to all Tapestry committers under their generous open-source policy.  This is one of the
+  IntelliJ is available to all Tapestry committers under JetBrains' generous open-source policy.  This is one of the
   perks of being invited as a committer.
   
 Builds

Copied: tapestry/tapestry5/trunk/src/site/apt/upgrade.apt (from r673794, tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade.apt)
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/apt/upgrade.apt?p2=tapestry/tapestry5/trunk/src/site/apt/upgrade.apt&p1=tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade.apt&r1=673794&r2=678187&rev=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/tapestry-core/src/site/apt/upgrade.apt (original)
+++ tapestry/tapestry5/trunk/src/site/apt/upgrade.apt Sat Jul 19 10:33:22 2008
@@ -9,11 +9,17 @@
 
   It is always advised to perform a full and complete build after upgrading.
 
-  You should also check the {{{../release-notes.html}project-wide release notes}} for information
+  You should also check the {{{release-notes.html}project-wide release notes}} for information
   about bugs fixes and other improvements.
 
 Release 5.0.14
 
+  Attempting to instantiate a component class will now result in a runtime exception (this is a common
+  beginner's mistake, pages and components should be injected, not instantiated).
+
+  Properties files in message catalogs are now already read using the UTF-8 charset.  Unlike traditional
+  Java ResourceBundles, it is <not> necessary to use Java's <<<native2ascii>>> tool.
+
 Release 5.0.13
 
   As part of {{{https://issues.apache.org/jira/browse/TAPESTRY-2311}TAPESTRY-2311}}, there have been
@@ -22,6 +28,13 @@
 
 Release 5.0.12
 
+* ClassFabUtils
+
+  Several methods of {{{../apidocs/org/apache/tapestry5/ioc/services/ClassFabUtils.html}ClassFabUtils}}
+  have been removed.  The new method {{{castReference()}}} is an improved replacement for the removed
+  methods. These methods were largely used when decorating services, and the new
+  {{{../apidocs/org/apache/tapestry5/ioc/services/AspectDecorator.html}AspectDecorator}} is even easier.
+
 * JavaScript Changes
 
   Tapestry now organizes JavaScript a bit differently; all JavaScript is at the bottom of the page, just
@@ -30,13 +43,13 @@
 
   This can cause some pages to break, those that included inline \<script\> blocks in their templates.
   You should inject the
-  {{{../apidocs/org/apache/tapestry5/RenderSupport.html}RenderSupport}} environmental and use it
+  {{{apidocs/org/apache/tapestry5/RenderSupport.html}RenderSupport}} environmental and use it
   to include JavaScript properly.
 
 * ReorderProperties annotation
 
   A new annotation,
-  {{{../apidocs/org/apache/tapestry5/beaneditor/ReorderProperties.html}ReorderProperties}}
+  {{{apidocs/org/apache/tapestry5/beaneditor/ReorderProperties.html}ReorderProperties}}
   (which is placed on a type) has replaced the OrderAfter and OrderBefore annotations
   (which were placed on accessor methods).
 
@@ -49,28 +62,28 @@
   In addition, a number of classes were refactored.
 
   PageRenderSupport has been renamed to just
-  {{{../apidocs/org/apache/tapestry5/RenderSupport.html}RenderSupport}}.
+  {{{apidocs/org/apache/tapestry5/RenderSupport.html}RenderSupport}}.
 
   TapestryConstants has been removed, split into a number of new classes (by type), such as
-  {{{../apidocs/org/apache/tapestry5/SymbolConstants.html}SymbolConstants}}.
+  {{{apidocs/org/apache/tapestry5/SymbolConstants.html}SymbolConstants}}.
 
   Likewise, TapestryUtils has been split into
-  {{{../apidocs/org/apache/tapestry5/MarkupUtils.html}MarkupUtils}} and
-  {{{../apidocs/org/apache/tapestry5/VersionUtils.html}VersionUtils}}.
+  {{{apidocs/org/apache/tapestry5/MarkupUtils.html}MarkupUtils}} and
+  {{{apidocs/org/apache/tapestry5/VersionUtils.html}VersionUtils}}.
 
   []
 
 * TapestryModule
 
   Many of the internal services of Tapestry have been split off into their own module,
-  {{{../apidocs/org/apache/tapestry5/internal/services/InternalModule.html}InternalModule}}.
+  {{{apidocs/org/apache/tapestry5/internal/services/InternalModule.html}InternalModule}}.
   This should not affect any user code.
 
 * Form component
 
-  The default {{{../apidocs/org/apache/tapestry5/ValidationTracker.html}ValidationTracker}}
+  The default {{{apidocs/org/apache/tapestry5/ValidationTracker.html}ValidationTracker}}
   built into the Form component now has a persistence strategy of "flash". This means that
-  if you navigate away from a page with validation errors and return, you will lose the errors
+  if you navigate away from a page with validation errors and return, you will lose the errors.
   To support this style of navigation, you will need to bind the Form's tracker parameter
   to a field that has the correct persistency (most likely, "session", the previous persistence
   strategy).
@@ -78,7 +91,7 @@
 * Resource.openStream()
 
   The methods <<<exists()>>> and <<<openStream()>>> were added to the
-  {{{../apidocs/org/apache/tapestry5/ioc/Resource.html}Resource}} interface. The semantics
+  {{{apidocs/org/apache/tapestry5/ioc/Resource.html}Resource}} interface. The semantics
   of some of the other methods were slightly alterred.
 
 * Loop element parameter
@@ -90,14 +103,14 @@
 
 * Field.getElementName()
 
-  The method <<<getElementName()>>> on interface {{{../apidocs/org/apache/tapestry5/Field.html}Field}}
+  The method <<<getElementName()>>> on interface {{{apidocs/org/apache/tapestry5/Field.html}Field}}
   was renamed to <<<getControlName()>>>.  This brings the property in alignment with W3C documentation
   and terminology, and helps differentiate from the element name (i.e., the tag name used to represent
   the element in a component template).
 
   This affects a number of existing components that implement the interface.
 
-  Method <<<allocateElementName()>>> on interface {{{../apidocs/org/apache/tapestry5/services/FormSupport.html}FormSupport}}
+  Method <<<allocateElementName()>>> on interface {{{apidocs/org/apache/tapestry5/services/FormSupport.html}FormSupport}}
   was likewise renamed to <<<allocateControlName()>>>.
 
 * Zone
@@ -110,25 +123,25 @@
 
 * Validator.invokeIfBlank()
 
-  The method <<<invokeIfBlank()>>> on interface {{{../apidocs/org/apache/tapestry5/Validator.html}Validator}}
+  The method <<<invokeIfBlank()>>> on interface {{{apidocs/org/apache/tapestry5/Validator.html}Validator}}
   was renamed to <<<isRequired()>>>.
 
 * MetaDataLocator
 
-  The <<findMeta()>> method on interface {{{../apidocs/org/apache/tapestry5/services/MetaDataLocator.html}MetaDataLocator}}
+  The <<findMeta()>> method on interface {{{apidocs/org/apache/tapestry5/services/MetaDataLocator.html}MetaDataLocator}}
   has changed significantly; it now expands symbols and performs type coercion.
 
 * Grid Interfaces
 
-  The {{{../apidocs/org/apache/tapestry5/grid/GridModel.html}GridModel}} interface and
+  The {{{apidocs/org/apache/tapestry5/grid/GridModel.html}GridModel}} interface and
   the <<<prepare()>>> method of 
-  {{{../apidocs/org/apache/tapestry5/grid/GridDataSource.html}GridDataSource}} have changed to accommodate
+  {{{apidocs/org/apache/tapestry5/grid/GridDataSource.html}GridDataSource}} have changed to accommodate
   the ability to sort using multiple columns.
 
 * PropertyModel
 
   The <<<getWidth()>>> method was removed from the
-  {{{../apidocs/org/apache/tapestry5/beaneditor/PropertyModel.java}PropertyModel}} interface; the logic
+  {{{apidocs/org/apache/tapestry5/beaneditor/PropertyModel.java}PropertyModel}} interface; the logic
   for deducing the desired field size from the @Width annotation has been moved into AbstractTextField.
 
 * Grid, BeanEditForm, BeanEditor, BeanDisplay
@@ -136,12 +149,12 @@
   The data type for boolean values has changed from "checkbox" (reflecting how it is rendered in an edit form) to "boolean"
   (reflecting what it is). In addition, all numeric types are given the data type "number".
   This will only affect your application if you provided an overriding contribution
-  to the {{{../apidocs/org/apache/tapestry5/services/BeanBlockSource.html}BeanBlockSource}} service.
+  to the {{{apidocs/org/apache/tapestry5/services/BeanBlockSource.html}BeanBlockSource}} service.
 
 * ExceptionInfo
 
   The return type for <<<getStackTrace()>>> on
-  {{{../apidocs/org/apache/tapestry5/services/ExceptionInfo.html}ExceptionInfo}}
+  {{{apidocs/org/apache/tapestry5/services/ExceptionInfo.html}ExceptionInfo}}
   changed from List\<String\> to List\<StackTraceElement\>.
 
 * ApplicationGlobals and RequestGlobals
@@ -151,7 +164,7 @@
 
 * BeanModel
 
-  The <<<remove()>>> method of {{{../apidocs/org/apache/tapestry5/beaneditor/BeanModel.html}BeanModel}} was renamed
+  The <<<remove()>>> method of {{{apidocs/org/apache/tapestry5/beaneditor/BeanModel.html}BeanModel}} was renamed
   to <<<exclude()>>>, and a new method, <<<include()>>> was added. The <<remove>> parameter of BeanEditForm,
   BeanEditor, BeanDisplay and Grid were all renamed to <<exclude>> as well (and a new <<include>> parameter was added
   to each).
\ No newline at end of file

Modified: tapestry/tapestry5/trunk/src/site/fml/faq/general.fml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/fml/faq/general.fml?rev=678187&r1=678186&r2=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/src/site/fml/faq/general.fml (original)
+++ tapestry/tapestry5/trunk/src/site/fml/faq/general.fml Sat Jul 19 10:33:22 2008
@@ -19,7 +19,7 @@
         </faq>
 
 
-       <faq id="classcastexception">
+        <faq id="classcastexception">
             <question>Why do I get a ClassCastException when I pass a page or component to a service?</question>
             <answer>
                 <p>
@@ -53,13 +53,13 @@
         </faq>
 
         <faq id="why-not-spring-guice">
-            <question>Why Tapestry IoC?  Why not use Spring or Guice?</question>
+            <question>Why Tapestry IoC? Why not use Spring or Guice?</question>
             <answer>
                 <p>
                     This comes up too frequently. Spring and Guice are very good containers, but are
-                    targetted at defining services for <em>applications</em>, not <em>frameworks</em>.
-    Tapestry has certain specific needs that are pervasive in the IoC layer, chief among them
-                    extensibility.  It must be possible to override internal services on a spot basis.
+                    targetted at defining services for<em>applications</em>, not<em>frameworks</em>.
+                    Tapestry has certain specific needs that are pervasive in the IoC layer, chief among them
+                    extensibility. It must be possible to override internal services on a spot basis.
                     It must be possible to extend the configuration of an existing service.
                 </p>
 
@@ -68,13 +68,16 @@
                     or by explicit name. To support Tapestry's level of extensibility, each new Tapestry
                     project would require a copy of a large Spring configuration file that would need to
                     be customized. Adding an additional layer, such as tapestry-hibernate, would
-                    add additional configuration into the configuration file.  This simply isn't the Tapestry way,
-                    where things <em>Just Work</em> (and where we avoid XML).
+                    add additional configuration into the configuration file. This simply isn't the Tapestry way,
+                    where things
+                    <em>Just Work</em>
+                    (and where we avoid XML).
                 </p>
 
                 <p>
                     Guice is very similar; there's no XML, but there are marker annotations used to select a specific
-                    implementaton from a pool of objects with the same interface. This means that Java code would have to be
+                    implementaton from a pool of objects with the same interface. This means that Java code would have
+                    to be
                     replaced in some cases, to slip overrides into place.
                 </p>
 
@@ -89,13 +92,13 @@
         <faq id="page-lifecycle-and-new">
 
             <question>
-                Why do I have to inject a page?  Why can't I just create one using <code>new</code>?
+                Why do I have to inject a page? Why can't I just create one using new?
             </question>
 
             <answer>
                 <p>
-                    As explained elsewhere, Tapestry tranforms your class at runtime.  It tends to build
-                    a large constructor for the class instance.  Further, an instance of the
+                    As explained elsewhere, Tapestry tranforms your class at runtime. It tends to build
+                    a large constructor for the class instance. Further, an instance of the
                     class is useless by itself, it must be wired together with its template
                     and its sub-components.
                 </p>
@@ -103,9 +106,10 @@
 
         </faq>
 
+
         <faq id="why-pool-pages">
             <question>
-                Why is it necessary to pool pages?  Couldn't they just be created fresh?  Or stored in the HttpSession?
+                Why is it necessary to pool pages? Couldn't they just be created fresh? Or stored in the HttpSession?
             </question>
 
             <answer>
@@ -117,7 +121,7 @@
 
                 <p>
                     Many of those objects are not serializable, and therefore, should not go into
-                    the HttpSession.  In addition, many of the objects are shared between page instances, but
+                    the HttpSession. In addition, many of the objects are shared between page instances, but
                     serialization is like a deep copy and would create duplicates of such objects.
                 </p>
 
@@ -132,107 +136,146 @@
                 <p>
                     It takes an appreciable amount of time to construct a working page instance, as all
                     those objects need to be instantiated, looked up, organized and wired together. It's barely
-                    noticable to a single developer, but a real site with real traffic, would find it unnacceptible
+                    noticable to a single developer, but a real site with real traffic would find it unnacceptible
                     to create a new page instance for each request.
                 </p>
 
                 <p>
                     Further, Tapestry's structure allows for a lot of optimizations and caching. This means that the
-                    <em>second</em> use of a page tends to be more efficient than the first, as most
+                    <em>second</em>
+                    use of a page tends to be more efficient than the first, as most
                     cacheable values have been cached.
                 </p>
             </answer>
         </faq>
 
-        <faq id="event-method-duplication">
 
+        <faq id="annotations-vs-naming-conventions">
             <question>
-                Why are my methods getting invoked multiple times?
+                Which is better, explict annotatations such as
+                OnEvent or
+                BeginRender
+                or using the naming conventions, such as
+                onAction()
+                or beginRender()?
             </question>
-
             <answer>
                 <p>
-                   There are some odd edge cases involving inheritance and
-                    render phase methods.  Here's an example:
+                    Both options have their place. In my experience, the naming convention option is very good
+                    for fast development, especially for prototyping. This is an area of great subjectivity, some
+                    developers
+                    will find the annotations more readable and maintainable, others will find the same for the
+                    naming convention approach.
+                </p>
+
+                <p>
+                    Historically, the annotations came first, and the naming conventions were "overlayed" on top of
+                    them.
                 </p>
 
-<source><![CDATA[
+                <p>
+                    One advantage of using annotations, is that the method name can now be descriptive of what
+                    the method does (i.e.,
+                    <code>validateUserCredentials()</code>
+                    instead of
+                    <code>onValidateFormFromLogin()</code>).
+                </p>
 
-public class BasePage
-{
-    void beginRender()
-    {
-        System.out.println("BasePage -- beginRender()");
-    }
-}
+                <p>
+                    Annotations have a further advantage in that the attributes of the annotation can be
+                    constants, rather than literals:
+                </p>
 
-public class ChildPage
-{
-    void beginRender()
-    {
-        System.out.println("ChildPage -- beginRender()");
-    }
-}
+                <pre>
+                    private static final String LOGIN = "login";
 
-]]>  (sorry about the CDATA, it's a typical Maven bug, please ignore)</source>
+                    @OnEvent(value=Form.VALIDATE_FORM, component=LOGIN)
+                    void validateUserCredentials()
+                    {
+                    ...
+                    }
+                </pre>
 
                 <p>
-                 Because there is a beginRender() method in the BasePage class, it will be invoked as part
-                    of the BeginRender phase. However, it is overridden by an identical ChildPage method.
-                    So the ChildPage method gets invoked once.
+                    This helps the compiler check your code for typos, and mnimizes the difficult of change when
+                    refactoring the names of components.
                 </p>
 
+            </answer>
+        </faq>
+
+        <faq id="component-vs-injectcomponent">
+
+            <question>
+                Should I use @Component or @InjectComponent?
+            </question>
+
+            <answer>
                 <p>
-                    However, ChildPage also provides a beginRender() (an override of the parent class), so
-                    this method also gets invoked ... for a second time.
+                    They both have their uses. The basic reasoning is derived from<em>where the component type is
+                    defined</em>.
                 </p>
 
                 <p>
-                    You can't turn off base class method invocations; what you can and should do is
-                    make your event handler methods in a base class <code>final</code>.
+                    Every component must have a specific type, a Java class that the framework can instantiate. This can
+                    come from a number of places:
                 </p>
 
-
+                <ul>
+                    <li>
+                        When the component is defined in the template using a
+                        <em>t:type</em>
+                        element name, the type is
+                        defined by the element name.
+                    </li>
+                    <li>
+                        When the component is a normal element, but has the t:type attribute, the type is defined
+                        by the attribute value.
+                    </li>
+                    <li>
+                        When the component is a normal element and has the t:id attribute, there
+                        <em>must</em>
+                        be
+                        a corresponding @Component annotation to define the type.
+                    </li>
+                </ul>
+
+                <p>
+                    The @InjectComponent annotation does not define the type of the component. The component type
+                    must be defined else where. The field that is annotated does not have to precisely match
+                    the component's actual type: it can be a super-class instead, or an interface implemented by the
+                    component.
+                </p>
 
             </answer>
 
+
         </faq>
 
-    </part>
 
+        <faq>
+            <question>
+                Why are there both Request and HttpServletRequest?
+            </question>
+            <answer>
+                <p>Tapestry's Request interface is
+                    <em>very</em>
+                    close
+                    to the standard HttpServletRequest interface. It differs in just a few ways, omitting
+                    a number of unneeded methods, adding a couple
+                    of methods (such as isXHR()) and changing how a few of the existing methods
+                    operate. for example, getParameterNames() returns a sorted List of Strings;
+                    HttpServletRequest returns an Enumeration, which is a very dated approach.
+                </p>
 
-    <!--
-<part id="General">
- <faq id="dead-doo-dad">
-   <question>My doo-dad is dead. How can I regenerate it?</question>
-   <answer>
-     <p>
-       Doo-dad generation happens at system boot. Therefore, the simplest
-       answer is to restart the hello-world-doodad service.
-     </p>
-     <p>
-       If your doodad service is widget-enabled, you can also regenerate
-       dead doo-dads using the /widgets/reincarnate.doodad address and the
-       following message data:
-     </p>
-     <source>
-       <reincarnation>
-         <id>1</id>
-         <password>ThisShouldBeEncrypted</password>
-       </reincarnation>
-     </source>
-   </answer>
- </faq>
- <faq id="what-is-a-doo-dad">
-   <question>What the h@!! is a doo-dad anyway?</question>
-   <answer>
-     <p>
-       Doo-dads are components of the hello-world system used to obfuscate
-       the misdirection server. It is critical to system health that the
-       doo-dad pool have an appropriate threshold and that it be culled
-       regularly.
-     </p>
-   </answer>
- </faq>
-</part>     -->
+                <p>
+                    However, the stronger reason for Request (and Response and Session, etc.)
+                    is for support of Portlets in the future. By writing your code in terms of
+                    Request, and not HttpServletRequest, you can be assured that the same
+                    code will operate in both Servlet Tapestry and Portlet Tapestry.
+                </p>
+            </answer>
+        </faq>
+
+    </part>
 </faqs>
\ No newline at end of file

Modified: tapestry/tapestry5/trunk/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/src/site/site.xml?rev=678187&r1=678186&r2=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/src/site/site.xml (original)
+++ tapestry/tapestry5/trunk/src/site/site.xml Sat Jul 19 10:33:22 2008
@@ -46,6 +46,11 @@
             <item name="FAQ" href="faq/general.html"/>
         </menu>
 
+        <menu name="Upgrade Notes">
+            <item name="From Tapestry 5" href="upgrade.html"/>
+            <item name="From Tapestry 4" href="upgrade4.html"/>
+        </menu>
+
         <menu name="Tapestry 5 Modules">
             <item name="tapestry-annotations" href="tapestry-annotations/"/>
             <item name="tapestry-core" href="tapestry-core/"/>
@@ -60,6 +65,12 @@
             <item name="Tutorial #1" href="tutorial1/"/>
         </menu>
 
+        <menu name="Tapestry Cookbook">
+            <item name="Introduction" href="cookbook/"/>
+            <item name="Supporting Informal Parameters" href="cookbook/informals.html"/>
+            <item name="Default Parameter" href="cookbook/defaultparameter.html"/>
+        </menu>
+
         <menu name="Tapestry 5 Maven Support">
             <item name="quickstart" href="quickstart/"/>
             <item name="tapestry-component-report" href="tapestry-component-report/"/>

Modified: tapestry/tapestry5/trunk/tapestry-core/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/site/site.xml?rev=678187&r1=678186&r2=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/tapestry-core/src/site/site.xml (original)
+++ tapestry/tapestry5/trunk/tapestry-core/src/site/site.xml Sat Jul 19 10:33:22 2008
@@ -52,11 +52,6 @@
             <item name="Download" href="http://tapestry.apache.org/download.html"/>
         </menu>
 
-        <menu name="Upgrade Notes">
-            <item name="From Tapestry 5" href="upgrade.html"/>
-            <item name="From Tapestry 4" href="upgrade4.html"/>
-        </menu>
-
         <menu name="User Guide">
             <item name="Project Layout" href="guide/project-layout.html"/>
             <item name="Component Classes" href="guide/component-classes.html"/>

Modified: tapestry/tapestry5/trunk/tapestry-ioc/src/site/site.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-ioc/src/site/site.xml?rev=678187&r1=678186&r2=678187&view=diff
==============================================================================
--- tapestry/tapestry5/trunk/tapestry-ioc/src/site/site.xml (original)
+++ tapestry/tapestry5/trunk/tapestry-ioc/src/site/site.xml Sat Jul 19 10:33:22 2008
@@ -43,7 +43,6 @@
 
         <menu name="Quick Links">
             <item name="Download" href="http://tapestry.apache.org/download.html"/>
-            <item name="Upgrade Notes" href="upgrade.html"/>
         </menu>
 
         <menu name="Tapestry IoC Container">