[CONF] Apache Tapestry > IoC cookbook - basics

2010-11-25 Thread confluence







IoC cookbook - basics
Page edited by Bob Harner


Comment:
fixed {code} syntax errors and  in code


 Changes (12)
 



...
The PropertyAccess service is defined inside TapestryIOCModule's bind() method:  
{code|borderStyle=solid} 
{code} 
  public static void bind(ServiceBinder binder)   { 
...
This example includes [ExceptionAnalyzer|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ExceptionAnalyzer.html], because it has a dependency on PropertyAccess:  
{code|borderStyle=solid} 
{code} 
public class ExceptionAnalyzerImpl implements ExceptionAnalyzer { 
...
In the previous example, we relied on the fact that only a single service implements the PropertyAccess interface. Had more than one done so, Tapestry would have thrown an exception when the ExceptionAnalyzer service was realized (it isn't until a service is realized that dependencies are resolved).  
That's normally okay; in many situations, it makes sense that only a single service implement a particular interface. 
 But there are often exceptions to the rule, and in those cases, we must provide more information to Tapestry when a service is defined, and when it is injected, in order to disambiguate -- to inform Tapestry which particular version of service to inject. 
...
Tapestry defines two such services, in the [TapestryModule|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/TapestryModule.html].  
{code|borderStyle=solid} 
{code} 
  @Marker(ClasspathProvider.class)   public AssetFactory buildClasspathAssetFactory(ResourceCache resourceCache, 
...
Here's an example. Again, we've jumped the gun with this _service contributor method_ (we'll get into the why and how of these later), but you can see how Tapestry is figuring out which service to inject based on the presence of those annotations:  
{code|borderStyle=solid} 
{code} 
public void contributeAssetSource(MappedConfiguration contributeAssetSource(MappedConfiguration configuration, 
  @ContextProvider   AssetFactory contextAssetFactory, 
...
  AssetFactory classpathAssetFactory)   { 
configuration.add("context", configuration.add("context", contextAssetFactory); 
configuration.add("classpath", configuration.add("classpath", classpathAssetFactory); 
  }{code}  
...

Full Content

Basic Services and Injection

A good part of the basics is convention: what to name your classes, what packages to put them in and so forth.

In many cases, these conventions are just a little stronger: you may have to do some amount of extra configuration if you choose to go your own way.

Getting Started

Like anything else, you want to choose a package for your application, such as org.example.myapp.

By convention, services go in a package named "services".

Module classes are suffixed with "Module".

Thus, you might start with a module class org.example.myapp.services.MyAppModule.

Simple Services

The simplest services don't have any special configuration or dependencies. They are defined as services so that they can be shared.

For example, the PropertyAccess service is used in multiple places around the framework to access properties of objects (its a wrapper around the Java Beans Introspector and a bit of reflection). This is defined in the TapestryIOCModule.

It's useful to share PropertyAccess, because it does a lot of useful caching internally.

The PropertyAccess service is defined inside TapestryIOCModule's bind() method:



  public static void bind(ServiceBinder binder)
  {
. . .
binder.bind(PropertyAccess.class, PropertyAccessImpl.class);
binder.bind(ExceptionAnalyzer.class, ExceptionAnalyzerImpl.class);
. . .
  }


This example includes ExceptionAnalyzer, because it has a dependency on PropertyAccess:



public class ExceptionAnalyzerImpl implements ExceptionAnalyzer
{
private final PropertyAccess propertyAccess;

public ExceptionAnalyzerImpl(PropertyAccess propertyAccess)
{
this.propertyAccess = propertyAccess;
}

. . .
}


And that's the essence of Tapestry IoC right there; the bind() plus the constructor is all that's necessary.

Service Disambiguation

In the previous example, we relied on the fact that only a single service implements the PropertyAccess interface. Had more than one done so, Tapestry would have thrown an exception when the ExceptionAnalyzer service was realized (it isn't until a service is

[CONF] Apache Tapestry > Introduction

2010-11-25 Thread confluence







Introduction
Page edited by Bob Harner


Comment:
Spelling, grammar, phrasing, version number updates, tense correction, etc


 Changes (17)
 



...
Apache Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server.  
Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with adding a small amounts of Java code. java class for each. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects -- and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications. 
 Tapestry is specifically designed to make creating new components very easy, as this is a routine approach when building applications. 
...
h2. Roadmap  
Now that that 5.0 release is finally out and available, work is rounding out on the 5.1 release. 
The 5.1 release is out and available now, work is winding down on the imminent 5.2 release, and developers are beginning to focus on 5.3. 
 The goal is to produce such releases on a regular schedule, every 4 - 6 months.  
High priorities for 5.2 upcoming releases include Spring Web Flow integration, and support for developing Tapestry applications as Portlets. 
Third Party Libraries, Tutorials and Resources 
 
h2. Third Party Libraries, Tutorials and Resources  
A number of Third Party Libraries, Tutorials and Resources are listed on the Tapestry Home Page.  
...
This short snippet demonstrates a bit about how Tapestry operates. Pages and services within the application are injected with the @Inject annotation. The method names, onValidateForm() and onSuccess(), inform Tapestry about when the method is to be invoked. The two events validateForm and success occur when a form is submitted; "validateForm" is triggered to perform cross-field validations, and "success" is only triggered when there are no validation errors. The onSuccess() method's return value directs Tapestry on what to do next: jump to another page within the application (here identified as the class for the page, but many other options exist). When there are exceptions, the page will be redisplayed to the user.  
This also represents a distinct change from Tapestry 4. In earlier versions of Tapestry, the Form component's listener parameter would be bound to the method to invoke, by name. Further, the listener method had to be public. This new approach not only supports multiple listeners, but provides an improved separation of view concerns (inside the page's HTML template) and logic concerns, (inside the Java class). 
 
In many cases, additional information about the event is available, and it can be passed into the method by adding parameters to the method. Again, Tapestry will adapt to your parameters, in whatever order you supply them. 
 Tapestry also saves you effort: the @Property annotation marks a field as readable and writable; Tapestry will provide the accessor methods automatically.  
Finally, Tapestry 5 explicitly separates actions (requests that change things) and rendering (requests that render pages) into two separate requests. Performing an action, such as clicking a link or submitting a form, results in a client side redirect to the new page. This is often approach, called "redirect after post". This post", helps ensure that URLs in the browser are book-markable ... -- but it also requires that a bit more information be stored in the session between requests (using the @Persist annotation). 
 h2. About Snapshots and Releases 
...
The use of Maven has let us move with great speed, providing preview releases and snapshots.  
Snapshots are intermediate versions of releases. As I'm writing this, of this writing, the most recent preview release is 5.0.2 and the current snapshots are for 5.0.3-SNAPSHOT. Maven keys off the -SNAPSHOT suffix and handles the dependency specially. It knows that snapshot releases can change frequently, so it will keep checking (at least once a

[CONF] Apache Tapestry > Home

2010-11-25 Thread confluence







Home
Page edited by Bob Harner


 Changes (4)
 



...
From here you can go to  
* [Index] \- -- the entry page for the auto-generated website 
* [Documentation] \- -- the documentation main page 
* [Sandbox] \- -- a sandbox for developing new ideas and testing things out 
* [TAPESTRY:Board Reports] \- -- Quarterly reports to the Apache Board 

Full Content

This is the home page of the Apache Tapestry wiki.

From here you can go to


	Index – the entry page for the auto-generated website
	Documentation – the documentation main page
	Sandbox – a sandbox for developing new ideas and testing things out
	Board Reports – Quarterly reports to the Apache Board





Change Notification Preferences

View Online
|
View Changes









[CONF] Apache Tapestry > Developer Bible

2010-11-25 Thread confluence







Developer Bible
Page edited by Bob Harner


Comment:
Removed duplicate Copyright section, minor formatting, para wrapping and de-"I"-ifying


 Changes (92)
 



...
h3. IntelliJ  
It's a free license for all committers and it's just better. Yes, the first few days can be an unpleasant fumble because everything is almost, but not quite, familiar.  Pretty soon you'll love IDEA and recognize that Eclipse has been bending you over and doing unspeakable things. 
can be an unpleasant fumble because everything is almost, but not quite, familiar.  Pretty soon you'll love IDEA and recognize that Eclipse has been bending you over and doing unspeakable things. 
 
There are shared code formatting settings in _.  This will prevent unexpected conflicts due to formatting. 
unexpected conflicts due to formatting. 
 h3. Eclipse  
Howard uses this ... because he can't manage to switch IDEs constantly (he uses Eclipse for training). Lately its gotten better. 
its gotten better. 
 h2. Copyrights  
All source files should have a the ASF copyright comment on top, except where such a comment would interfere with its behavior.  For example, component template files omit the comment. 
would interfere with its behavior.  For example, component template files omit the comment. 
 
The year on the copyright should be updated as a file changes.  As you are reviewing your changes before checking them in, try to check the copyright date, and add the current year to the list if not present. 
As you make changes to files, update the copyright to add the current year to the list.  The goal is that the copyright notice includes the year in which files change.  When creating a new file, don't back date the copyright year ... start with the current year.  Try not to change the copyright year on files that haven't actually changed. 
 
IntelliJ has a great comparison view: Cmd-9 to see the local changes, the Cmd-D to see the differences. You can whip through the changes (using Cmd-forward arrow) and make sure copyrights are up to date as you review the changes prior to a commit.  
h2. Commit Messages  
Always provide a commit message.  I Howard generally try tries to work off the JIRA, so my his commit message is often: 
 bq. TAP5-1234: Make the Foo Widget more Ajax-tastic!  
It is _very important_ to include the JIRA issue id in the commit.  This is used in many places: JIRA links issues to the SVN commits for that issue (very handy for seeing what changed as part of a bug fix).  The Hudson CI server does as well, and will actually link SVN commits to issues after succesfully building. 
 
It is _very important_ to include the JIRA issue id in the commit.  This is used in many places: JIRA links issues to the SVN commits for that issue (very handy for seeing what changed as part of a bug fix).  The Hudson CI server does as well, and will actually link SVN commits to issues after succesfully building.  
h2. JIRA Procedures  All Tapestry committers should be registerred with JIRA and part of the tapestry-developers JIRA group.  
I work Howard works the following JIRA list: [JIRA Work Queue|https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311597]. 
 
Ideally, we would always work top priortity to low priority.  Howard sometimes jump out of order, if there's something cool to work on that fits in an available time slot.  Alternately, you are always allowed to change the priority of a bug before or as you work it. 
 
Ideally, we would always work top priortity to low priority.  I (Howard) sometimes jump out of order, if there's something cool to work on that fits in an available time slot.  Alternately, you are always allowed to change the priority of a bug before or as you work it.  
h3. Starting work
When you start to work on an issue, make sure it is _assigned to you_ and use the _start progress_ option. 
option. 
 
I often add Add comments about the state of the fix, or the challenges in creating a fix.  This often spurs the Issue's adder to 
provide more details.  
I often update the issue description to make it more legible and more precise, i.e., "NPE in CheckUpdates" 
Update the issue description to make it more legible and more precise if needed, i.e., "NPE in CheckUpdates" might become "NullPointerException when checking for updates to files that have been deleted".  Verbose is good. 
 h3. Closing bugs

[CONF] Apache Tapestry > Wiki Status

2010-11-25 Thread confluence







Wiki Status
Page  added by Bob Harner

 

 This page provides some basic information about the status of the Tapestry documentation wiki.








 


Recently Updated






 by
Bob Harner
(20 minutes ago)





IoC - advice






 by
Christophe Cordenier
(4 hours ago)





IoC cookbook - patterns






 by
Christophe Cordenier
(4 hours ago)





Layout Component






 by
Christophe Cordenier
(4 hours ago)





Page Navigation






 by
Christophe Cordenier
(4 hours ago)





Input Validation






 by
Christophe Cordenier
(4 hours ago)





Forms2






 by
Christophe Cordenier
(4 hours ago)





Upload






   

[jira] Commented: (TAP5-1355) Threading issue with SessionStateObjects

2010-11-25 Thread Andy Blower (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935740#action_12935740
 ] 

Andy Blower commented on TAP5-1355:
---

May I ask why my original patch to fix the issue TAP5-834 is not being 
considered. I was pretty surprised that it was not used in the first place, but 
the second way of fixing the issue was chosen which had possible concurrency 
issues. My original words:

"I think there are two possible solutions to this issue - I prefer the first by 
a large margin, but both modify the SessionImpl.restoreDirtyObjects() method.

1) Add a new method to OptimizedSessionPersistedObject interface to reset the 
dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer - 
implementing them as appropriate, then call the new reset method after setting 
the session attribute in SessionImpl.restoreDirtyObjects().

2) Remove the session attribute before adding it in 
SessionImpl.restoreDirtyObjects(). Although I have a worry that this may 
potentially cause hard to find concurrency problems."

The second solution was used, but the first solution (which my patch 
implemented)  is much better. I know it adds a new method to a public 
interface, but this is not as much impact as changing or removing an existing 
method one and in this case is trivial for users to implement. There has 
certainly been worse backwards compatibility changes made in T5, and the 
benefit of this simple solution (#1 above) far outweighs the impact IMHO. It's 
also a lot simpler and cleaner than the solutions proposed here. Also IMHO.

Just FYI the code from the patch was run in our production environment for 
several months before we upgraded to Tapestry 5.2 and removed my 
customizations. Luckily we don't seem to have run into any threading issues, 
well not that have caused any fuss at least.

> Threading issue with SessionStateObjects
> 
>
> Key: TAP5-1355
> URL: https://issues.apache.org/jira/browse/TAP5-1355
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.2.4
>Reporter: Moritz Gmelin
> Attachments: Screenshot.png.jpg, taptest.tgz
>
>
> When a page request consists of multiple HTTP request (e.g. page and some 
> dynamically generated images) and all those requests access a 
> SessionStateObject, it happens that a new session (with an empty SSO) is 
> created for some of the request threads.
> I was able to create a very simple example to recreate that problem:
>   -A simple page that displays 20 dynamically generated images in a loop.
>   -In the page, a SSO, holding a number value is initialized to a random 
> number.
>   -Each of the dynamic images read that number and draws it.
>   -Make sure that a HTTP-Request is made for every image on the page (by 
> adding some random number to the event link)
> The effect that you'll see after some reloads of the page (maybe you need to 
> reload 30 times) is that some images will draw 0 as SSO value instead of the 
> number set in the page @BeginRender method. Those fields will be marked in 
> red in the demo so you can quickly see them. 
> I definitely beleive that tapestry should take care of this. It is a use case 
> for SSOs that is probably too common to ignore. 
> Why can't this be automatically integrated into the ApplicationStateManager?
>  
> The demo has been deployed here
> http://www.avetana.de/taptest/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (TAP5-1354) New T5 site remarks

2010-11-25 Thread Christophe Cordenier (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christophe Cordenier reassigned TAP5-1354:
--

Assignee: Christophe Cordenier

> New T5 site remarks
> ---
>
> Key: TAP5-1354
> URL: https://issues.apache.org/jira/browse/TAP5-1354
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Borut Bolcina
>Assignee: Christophe Cordenier
>
> Hello,
> first congratulations on a new site!
> Today I needed some information about how to test my services, so I visited 
> the new site and started browsing. Couldn't find the answer. Can someone give 
> me some pointers here?
> First I looked in the FAQ and searched for "test" within the page with my 
> browser. Found 2 irrelevant hits, so I went on to the User guide. There is a 
> section Test, but covers only testing of pages.
> Inspecting further to Tapestry IOC and eye-balling for something useful I 
> discovered a link to registry startup, which briefly mentions what would one 
> want to use it:
> "However, you may want to do some integration testing using the Registry from 
> within a test case,"
> I know there are projects out there, so you can inspect the source code to 
> get an example of how to test the services, but I feel it should be better 
> explained right on the offical page - at least in the FAQ section. It is very 
> hard to embrace testing to start with, so some guidance is much appreciated.
> And the red background links must go away.
> The download section should include maven instruction, at least the 
> dependency section of the pom should be listed.
> There should be more room at the bottom between the last paragraph and the 
> footer. The header on most pages is very "white", the bottom has no space at 
> all. Give it some air.
> Why is there a Book section in the Documentation with only one link to more 
> books? It look like an error. At least last two books (their images and 
> caption) should be there.
> I like the ComponentCheetSheet! A sentance or two more on each annotation 
> would be great.
> The tutorial Setting up your environment should be improved. Alternatives 
> should be described on how to run T5 apps in the Eclipse or other IDEs, but 
> not in the text as that would make it too long. I think there should be links 
> for alternative setups - like how to run the T5 app from a main class and 
> even start VisualVM for early debugging and optimizing (each alternative has 
> pros and cons). There is no mention of m2eclipse plugin. Of course one can 
> use JDK 6 also - only 1.5 is there. There is a sentence: "You should not have 
> to download this directly". Why are then download links on the download page 
> and no mention of maven at the same time. It is confusing for newbs.
> The should also be a more visible link to T5 wiki somewhere.
> I hope I wasn't too harsh, just wanna put my perspective.
> -Borut

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[CONF] Apache Tapestry > IoC cookbook - patterns

2010-11-25 Thread confluence







IoC cookbook - patterns
Page edited by Christophe Cordenier


Comment:
Fix broken links


 Changes (1)
 



...
h1. Chain of Command Pattern  
Let's look at another example, again from the Tapestry code base. The [InjectProvider|../../apidocs/org/apache/tapestry5/services/InjectionProvider.html] [InjectProvider|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/InjectionProvider.html] interface is used to process the @Inject annotation on the fields of a Tapestry page or component. Many different instances are combined together to form a [chain of command|../command.html]. command|IoC - command]. 
 The interface has only a single method (this is far from uncommon): 
...

Full Content

Using Patterns

Tapestry IoC has support for implementing several of the Gang Of Four Design Patterns. In fact, the IoC container itself is a pumped up version of the Factory pattern.

The basis for these patterns is often the use of service builder methods, where a configuration for the service is combined with a factory to produce the service implementation on the fly.

Chain of Command Pattern

Let's look at another example, again from the Tapestry code base. The InjectProvider interface is used to process the @Inject annotation on the fields of a Tapestry page or component. Many different instances are combined together to form a chain of command.

The interface has only a single method (this is far from uncommon):

Unknown macro: {code|borderStyle=solid} 
public interface InjectionProvider
Unknown macro: {
  boolean provideInjection(String fieldName, Class fieldType, ObjectLocator locator,
  ClassTransformation transformation, MutableComponentModel componentModel);
} 



The return type indicates whether the provider was able to do something. For example, the AssetInjectionProvider checks to see if there's an @Path annotation on the field, and if so, converts the path to an asset, works with the ClassTransformation object to implement injection, and returns true to indicate success. Returns true terminates the chain early, and that true value is ultimately returned to the caller.

In other cases, it returns false and the chain of command continues down to the next provider. If no provider is capable of handling the injection, then the value false is ultimately returned.

The InjectionProvider service is built up via contributions. These are the contributions from the TapestryModule:

public static void contributeInjectionProvider(
OrderedConfiguration configuration,
MasterObjectProvider masterObjectProvider,
ObjectLocator locator,
SymbolSource symbolSource,
AssetSource assetSource)
Unknown macro: {
  configuration.add("Default", new DefaultInjectionProvider(masterObjectProvider, locator));

  configuration.add("ComponentResources", new ComponentResourcesInjectionProvider());

  configuration.add(
  "CommonResources",
  new CommonResourcesInjectionProvider(),
  "after} 


And, of course, other contributions could be made in other modules ... if you wanted to add in your own form of injection.

The configuration is converted into a service via a service builder method:

{code|borderStyle=solid}
  public InjectionProvider build(List configuration, ChainBuilder chainBuilder)
  {
return chainBuilder.build(InjectionProvider.class, configuration);
  }


Now, let's see how this is used. The InjectWorker class looks for fields with the InjectAnnotation, and uses the chain of command to inject the appropriate value. However, to InjectWorker, there is no chain ... just a single object that implements the InjectionProvider interface.

Unknown macro: {code|borderStyle=solid} 
public class InjectWorker implements ComponentClassTransformWorker
{
  private final ObjectLocator locator;

  // Really, a chain of command

  private final InjectionProvider injectionProvider;

  public InjectWorker(ObjectLocator locator, InjectionProvider injectionProvider)
  Unknown macro: {
this.locator = locator;
this.injectionProvider = injectionProvider;
  } 

  public final void transform(ClassTransformation transformation, MutableComponentModel model)
  {
for (String fieldName : transformation.findFieldsWithAnnotation(Inject.class))
{
  Inject annotation = transformation.getFieldAnnotation(fieldName, Inject.class);

  try
  Unknown macro: {
String fieldType = transformation.getFieldType(fieldName);

Class type = transformation.toClass(fieldType);

boolean success = injectionProvider.provideInjection(
fieldName,
type,
locator,
transformation,
model);

if (success) transformation.claimField(fieldNam

[CONF] Apache Tapestry > Layout Component

2010-11-25 Thread confluence







Layout Component
Page edited by Christophe Cordenier


Comment:
Fix links on component reference


 Changes (1)
 



h1. Layout Component  
You may see frequent reference to a Layout Component, but you won't find it in the [component reference|../tapestry-core/ref/index.html]. reference|http://tapestry.apache.org/current/tapestry-core/ref/index.html]. Layout isn't a component, it's a component _pattern_. 
 A Layout component exists to provide common content across all pages in your application. In traditional servlet development, you may be familiar with the use of a JSP include to include a banner across the top of your page and a copyright message across the bottom. 
...

Full Content

Layout Component

You may see frequent reference to a Layout Component, but you won't find it in the component reference. Layout isn't a component, it's a component pattern.

A Layout component exists to provide common content across all pages in your application. In traditional servlet development, you may be familiar with the use of a JSP include to include a banner across the top of your page and a copyright message across the bottom.

Tapestry doesn't have a mechanism for such includes, nor does it have the need.

Instead, you can create a component that acts like a template for your pages.

Layout.tml




My Nifty Web Application



Nifty Web Application





(C) 2008 NiftyWebCo, Inc.






Layout is a standard component, with a standard component template. Like all component templates, it will be stored on the classpath (i.e., under src/main/resources).

The magic is in the  element in the center; this will be replaced by the page's content, whatever that is.

The two  elements above and below the  are, in this example, placeholders for the typical content you'll see in a web application: banners (and banner ads!), menus, login forms and so forth.

Often these get very complex ... in fact, in most applications, the Layout component grows to be more complex than almost any page in the application.

Remember that if you include a link to a resource such as an image or a stylesheet, you must use an absolute URL. The same component will be used for pages in many different folders, or with many different activation contexts, meaning that relative URLs are not only different for different pages, but may shift unexpectedly.

Layout.java


@IncludeStylesheet("context:css/site.css")
public class Layout
{
}



Components must always have a Java class. In this trivial example, the Layout component does not have much logic. We can save ourselves some typing using the @IncludeStylesheet annotation (as opposed to directly adding the  element to the template.

Index.tml




   Welcome to the Nifty Web Application!

   
Would you like to Log In?
   




This is an example of using the Layout component. To keep our Index.tml template relatively previewable, we are using an  element and the t:type attribute to specify that it is a component.

The  tag will be removed, and replaced with the content from the Layout.tml template (which convieniently starts with an  element). The  in Layout.tml will be replaced with the page specific content here: the  and  tags.

Any page in the application that follows this pattern, using the Layout component, will have the same look and feel.

You may find that your application has more than one look and feel: perhaps user registration pages have one look, while administrative pages have another. This can be accomplished by having multiple Layout components and using different layout types for different pages.




Change Notification Preferences

View Online
|
View Changes









[CONF] Apache Tapestry > Page Navigation

2010-11-25 Thread confluence







Page Navigation
Page edited by Christophe Cordenier


Comment:
Fix broken links


 Changes (5)
 



...
h1. Component Event Requests  
Component event requests may take the form of hyperlinks ([ActionLink|../ref/org/apache/tapestry5/corelib/components/ActionLink.html]) ([ActionLink|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/ActionLink.html]) or form submissions ([Form|../ref/org/apache/tapestry5/corelib/components/Form.html]). ([Form|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Form.html]). 
 In both cases, the value returned from an [event handler method|#event.html] controls the response sent to the client web browser. 
...
You may also return an instance of a page, rather than the name or class of a page.  
A page may be injected via the [InjectPage|../apidocs/org/apache/tapestry5/annotations/InjectPage.html] [InjectPage|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/InjectPage.html] annotation. 
 Often, you will configure the page in some way before returning the page (examples below). 
...
h2. Link response  
An event handler method may return a [Link|../apidocs/org/apache/tapestry5/Link.html] [Link|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Link.html] instance directly. The Link is converted into a URL and a client redirect to that URL is sent to the client. 
 
The [ComponentResources|../apidocs/org/apache/tapestry5/ComponentResources.html] [ComponentResources|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ComponentResources.html] object that is injected into your pages (and components) has methods for creating component event and page render links. 
 h2. Stream response  
An event handler can also return a [StreamResponse|../apidocs/org/apache/tapestry5/StreamResponse.html] [StreamResponse|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/StreamResponse.html] object, which encapsulates a stream to be sent directly to the client browser. This is useful for compnents that want to, say, generate an image or PDF and provide it to the client. 
 h2. URL response 
...

Full Content

Page Navigation

In essense, a Tapestry application is a number of related pages, working together. To some degree, each page is like an application unto itself.

Any individual request will be targetted at a single page. Requests come in two forms:


	component event requests target a specific component on a specific page, triggering an event within that component
	render requests target a specific page, and stream the HTML markup for that page back to the client
This dictomy between component event requests and render requests is new in Tapestry 5. It is in some ways based on ideas from the Portlet specification and differentiating the two types of requests alleviates a number of problems in traditional web applications related to the browser back button, or to the user hitting the refresh button in their browser.



Component Event Requests

Component event requests may take the form of hyperlinks (ActionLink) or form submissions (Form).

In both cases, the value returned from an event handler method controls the response sent to the client web browser.

The URL for a component event request identifies the name of the page, the nested id of the component, and the name of the event to trigger on the component (this is usually "action"). Further, a component event request may contain additional context information, which will be provided to the event handler method.

These URLs expose a bit of the internal structure of the application. Over time, as an application grows and is maintained, the ids of components may change. This means that component event request URLs should not be bookmarked. Fortunately, users will rarely have the chance to do so (see below).

Null response

If the event handler method returns no value, or returns null, then the current page (the page containing the component) will render the response.

A page render link for the current page is created and sent to the client as a client side redirect. The client browser will automatically submit a new request to generate the page.

The user will see the newly generated content in their browser. In addition, the URL in the browser's address bar will be a render request URL. Render request URLs are shorter and contain less application structure (for instance, they don't include component ids or event types). Render requests URLs are what your users will bookmark. The component event req

[CONF] Apache Tapestry > Input Validation

2010-11-25 Thread confluence







Input Validation
Page edited by Christophe Cordenier


Comment:
Fix links on component reference


 Changes (4)
 



...
h1. Form component  
The core of Tapestry's form support is the [Form|../tapestry-core/ref/org/apache/tapestry5/corelib/components/Form.html] [Form|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Form.html] component. The Form component encloses (wraps around) all the other _field components_ such as [TextField|../tapestry-core/ref/org/apache/tapestry5/corelib/components/TextField.html], [TextArea|../tapestry-core/ref/org/apache/tapestry5/corelib/components/TextArea.html], [Checkbox|../tapestry-core/ref/org/apache/tapestry5/corelib/components/Checkbox.html], [TextField|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/TextField.html], [TextArea|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/TextArea.html], [Checkbox|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Checkbox.html], etc. 
 The Form component generates a number of [component events|#event.html] that you may provide event handler methods for. 
...
{code}  
Because of the the fact that a form submission is _two_ requests (the submission itself, then a re-render of the page), it is necessary to make the value stored in the _userName field persist between the two requests. This would be necessary for the _password field as well, except that the [PasswordField|../tapestry-core/ref/org/apache/tapestry5/corelib/components/PasswordField.html] [PasswordField|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/PasswordField.html] component never renders a value. 
 Note that the onSuccess() method is not public; event handler methods can have any visibility, even private. Package private (that is, no modifier) is the typical use, as it allows the component to be tested, from a test case class in the same package. 
...
The Tapestry Form component is responsible for creating the necessary URL for the form submission (this is Tapestry's responsibility, not yours).  
The [Errors|../tapestry-core/ref/org/apache/tapestry5/corelib/components/Errors.html] [Errors|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Errors.html] component must be placed inside a Form, it outputs all of the errors for all the fields within the Form as a single list. It uses some simple styling to make the result more presentable. 
 
Each field component, such as the TextField, is paired with a [Label|../tapestry-core/ref/org/apache/tapestry5/corelib/components/Label.html] [Label|http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Label.html] component. The Label will render out a  element connected to the field. This is very important for useability, especially for users with visual disabilities. It also means you can click on the label text to move the cursor to the corresponding field. 
 The {{for}} parameter of the Label is the id of a component. 
...

Full Content

Form Input and Validation

The life's blood of any application is form input; this is the most effective way to gather significant information from the user. Whether it's a search form, a login screen or a multi-page registration wizard, forms are how the user really expresses themselves to the application.

Tapestry excels at creating forms and validating input. Input validation is declarative, meaning you simply tell Tapestry what validations to apply to a given field, and it takes care of it on the server and (once implemented) on the client as well.

Finally, Tapestry is able to not only present the errors back to the user, but to decorate the fields and the labels for the fields, marking them as containing errors (primarily, using CSS effects).

Form component

The core of Tapestry's form support is the Form component. The Form component encloses (wraps around) all the other field components such as TextField, TextArea, Checkbox, etc.

The Form component generates a number of component events that you may provide event handler methods for.

When rendering, the Form component emits two notifications: first, "prepareForRender", then "prepare". These allow the Form's container to setup any fields or properties that will be referenced in the form. For example, this is a good chance to create a temporary entity object to be rendered, or to load an entity from a database to be editted.

When user submits the form on the client,