[CONF] Apache Tapestry IndexV2
IndexV2 File attached by Katia Aresti injection.png (5 kB image/png) - injection Change Notification Preferences View Attachments
[CONF] Apache Tapestry IndexV2
IndexV2 File attached by Katia Aresti flag_green.png (1 kB image/png) - testability Change Notification Preferences View Attachments
[jira] Created: (TAP5-1376) The Introduction page is about Tapestry 5.1
The Introduction page is about Tapestry 5.1 --- Key: TAP5-1376 URL: https://issues.apache.org/jira/browse/TAP5-1376 Project: Tapestry 5 Issue Type: Bug Components: documentation Reporter: Borut Bolcina The Introductino page http://tapestry.apache.org/introduction.html needs rewriting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Tapestry IndexV2
IndexV2 File removed by Katia Aresti plugin.png (2 kB image/png) - adaptable Change Notification Preferences View Attachments
[CONF] Apache Tapestry IndexV2
IndexV2 File removed by Katia Aresti injection.png (5 kB image/png) - injection Change Notification Preferences View Attachments
[CONF] Apache Tapestry IndexV2
IndexV2 File attached by Katia Aresti injection.png (2 kB image/png) - injection Change Notification Preferences View Attachments
[CONF] Apache Tapestry IndexV2
IndexV2 File attached by Katia Aresti plugin.png (2 kB image/png) - plugin Change Notification Preferences View Attachments
[CONF] Apache Tapestry IndexV2
IndexV2 File attached by Katia Aresti plugin_add.png (2 kB image/png) - plugin Change Notification Preferences View Attachments
[jira] Commented: (TAP5-986) sendError in onActivate / Tapestry error dispatching
[ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12972664#action_12972664 ] Sebastian Arming commented on TAP5-986: --- Yes, the HttpError from TAP5-1174 leads to the same problem in 5.2.0 sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Attachments: TAP5-986.txt With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Tapestry Hibernate
Hibernate
Page edited by Bob Harner
Comment:
Added "Related Articles" box (using "hibernate" label)
Changes (2)
{float:right|background="" {contentbylabel:title=Related Articles|showLabels=false|showSpace=false|space=TAPESTRY|labels=hibernate} {float}
The *Tapestry/Hibernate Integration Library* provides out-of-the-box support for using Hibernate 3 as the back end for normal CRUD style Tapestry applications.
...
* Transactions are now _aborted_ (no longer _committed_) at the end of each request: you must now explicitly commit the transaction if changes are to be saved.
* The new @CommitAfter annotation for component and service methods can now commit the transaction automatically after the method is invoked.
* [HibernateGridDataSource|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/hibernate/HibernateGridDataSource.html] can be used with the Grid component to support optimized queries against large data sets.
Full Content
Related Articles
Userguide
Hibernate - Core - Conf
Hibernate - Core
Statistics
The Tapestry/Hibernate Integration Library provides out-of-the-box support for using Hibernate 3 as the back end for normal CRUD style Tapestry applications.
For at least the first pass, this will represent access to the native Hibernate interfaces, exposed in a thread-safe manner, within a session-per-request strategy.
Note that a number of the more esoteric ideas in Hibernate are not supported, including nested transactions and supporting multiple persistence units.
The tapestry-hibernate-core module allows non-Tapestry applications to access Hibernate.
Licensing Issues
Hibernate is licensed under the Lesser GNU Public License. This is more restrictive license than the Apache Software License used by the rest of Tapestry. The restrictions mostly apply to redistributing Hibernate, especially in any altered form, and will likely be irrelevant to the vast majority of users, but you should be aware.
This library is compiled against version 3.3.1.GA of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work with more recent versions.
What's New?
Transactions are now aborted (no longer committed) at the end of each request: you must now explicitly commit the transaction if changes are to be saved.
The new CommitAfter annotation for component and service methods can now commit the transaction automatically after the method is invoked.
HibernateGridDataSource can be used with the Grid component to support optimized queries against large data sets.
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry Announcing Tapestry 5.2
Announcing Tapestry 5.2
Blog post edited by Howard M. Lewis Ship
Changes (1)
{excerpt}Im very proud to announce that the next major release of Tapestry, release 5.2, is now available as [Tapestry version 5.2.4|Download].{excerpt}
This is the first stable release of Tapestry since 5.1.0.5 (back in April 2009), which is far too long a cycle. You might wonder: whats been the holdup? The answer, for myself personally, is that Ive been using Tapestry on two very, very different applications for two very, very different clients and Ive been updating Tapestry to embrace the real world concerns of both of them. At the same time, Ive done about a dozen public and private Tapestry training sessions and gathered reams of input from my students.
...
Full Content
I'm very proud to announce that the next major release of Tapestry, release 5.2, is now available as Tapestry version 5.2.4.
This is the first stable release of Tapestry since 5.1.0.5 (back in April 2009), which is far too long a cycle. You might wonder: what's been the holdup? The answer, for myself personally, is that I've been using Tapestry on two very, very different applications for two very, very different clients and I've been updating Tapestry to embrace the real world concerns of both of them. At the same time, I've done about a dozen public and private Tapestry training sessions and gathered reams of input from my students.
Let's talk about some of the major enhancements in this release:
Removal of Page Pooling
Prior versions of Tapestry used a page pool; for each page, Tapestry would track multiple instances of the page, binding one page instance to a particular request. This was an important part of Tapestry's appeal ... all the issues related to multi-threading were taken over by the framework, and you could code your pages and components as simple POJOs, without worrying about the threading issues caused by running inside a servlet container.
Unfortunately pages are big: it's not just one object but instead the root of a large tree of objects: components and templates, bindings for component parameters, component resources, and all the extra infrastructure (lists and maps and such) to tie it together. Some of the largest Tapestry projects have hit memory problems when they combined deeply componentized pages with large numbers of parallel threads.
Tapestry 5.2 rewrites the rules here; only a single page tree is now needed for each page; the page and component classes have an extra transformation step that moves per-request data out of the objects themselves and into a per-thread Map object. Now, any number of requests can operate at the same time, without requiring additional page instances. Even better, the old page pooling mechanism included some locking and blocking that also gets jettisoned in the new approach. It's just a big win all around.
Live Service Reloading
People love the ability to change page and component classes in a Tapestry application and see the changes immediately; prior to 5.2 the same people would be disappointed that they couldn't change their services and see changes just as immediately. Tapestry 5.2 eliminates that restriction in most cases.
This is super handy for services such as DAOs (data access objects) where it is now possible to tweak a Hibernate query and see the results as immediately as changing some content in a template. This is another Tapestry feature that you'll find you can't live without once you use it the first time!
ClassTransformation API Improvements
At the heart of Tapestry is the Class Transformation API; the extensible pipeline that is the basis for how Tapestry transforms simple POJOs into working components. Prior to 5.2, if you wanted to do any interesting transformations, you had to master the Javassist psuedo-Java language.
Tapestry 5.2 reworks the API; it is now possible to do all kinds of interesting transformations in strict Java code; Javassist has been walled off, with an eventual goal to eliminate it entirely.
Query Parameter Support
Tapestry traditionally has stored information in the HTTP request path. For example, a URL might be /viewaccount/12345; the viewaccount part of the URL is the name of a page, and the 12345 part is the ID of an Account object. Tapestry calls the latter part the page activation context (which can contain one or more values).
That works well when the a page has a fixed set of values for the page activation context, but not so well when the values may vary. For instance, you may be doing a search and want to store optional query parameters to identify the query term or the page number.
Tapestry 5.2 adds the @ActivationRequestParameter annotation that automates the process of gathering such data, encoding that data
[CONF] Apache Tapestry Cookbook
Cookbook
Page edited by Howard M. Lewis Ship
Changes (1)
...
{include:Enum Parameter Recipe} {include:Error Page Recipe}
{include:Extending the If Component}
Full Content
Contents
Contents
Introduction
Default Parameter
Overriding Exception Reporting
Version 1: Replacing the Exception Report Page
Version 2: Overriding the RequestExceptionHandler
Version 3: Decorating the RequestExceptionHandler
Supporting Informal Parameters
Creating Component Libraries
Step 1: Choose a base package name
Step 2: Create your pages and/or components
Step 3: Choose a virtual folder name
Step 4: Configure the virtual folder
Step 5: Configure the module to autoload
Step 6: Extending Client Access
Step 7: Versioning Assets
Conclusion
A note about Assets
Switching Cases
Enum Component Parameter
Serving Tapestry Pages as Servlet Error Pages
Introduction
The Tapestry Cookbook is a collection of tips and tricks for commonly occurring patterns in Tapestry.
Default Parameter
Many of the 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.
Let's say you have created a component, RichTextEditor, which operates like a normal TextArea component, but provides a _javascript_ rich text editor. You might start with something like:
public class RichTextEditor implements Field
{
@Property
@Parameter(required=true)
private String value;
. . . // Lots more code not shown here
}
However, the weakness here is when you make use of the component. You template may look like:
t:label for="" class="code-quote">"profile"/
br/
t:richtexteditor t:id="profile" value="profile"/
Every component has a unique id; if you don't assign one with the t:id attribute, Tapestry will assign a less meaningful one. Component ids can end up inside URLs or used as query parameter names, so using meaningful ids helps if you are ever stuck debugging a request. The most common case of using autoconnect is form control components such as TextField and friends ... or this RichTextEditor.
This repetition can be avoided by adding the autoconnect attribute to the @Parameter annotation:
@Property
@Parameter(required=true, autoconnect=true)
private String value;
This can now be written as t:richtexteditor t:id="profile"/. The unwanted repetition is gone: we set the id of the component and the property it edits in a single pass.
If there is no matching property, then a runtime exception will be thrown when loading the page because the value parameter is required and not bound.
Overriding Exception Reporting
One of Tapestry's best features is its comprehensive exception reporting. The level of detail is impressive and useful.
Of course, one of the first questions anyone asks is "How do I turn it off?" This exception reporting is very helpful for developers but its easy to see it as terrifying for potential users. Not that you'd have have runtime exceptions in production, of course, but even so ...
Version 1: Replacing the Exception Report Page
Let's start with a page that fires an exception from an event handler method.
Index.tml
html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"
head
titleIndex/title
/head
body
p
t:actionlink t:id="fail"click for exception/t:actionlink
/p
/body
/html
Index.java
package com.example.tapestry2523.pages;
public class Index
{
void onActionFromFail()
{
throw new RuntimeException("Failure inside action event handler.");
}
}
With production mode disabled, clicking the link displays the default exception report page:
The easy way to override the exception report is to provide an ExceptionReport page that overrides the one provided with the framework.
This is as easy as providing a page named "ExceptionReport". It must implement the ExceptionReporter interface.
ExceptionReport.tml
html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"
head
titleException/title
/head
body
pAn exception has occurred:
strong${exception.message}/strong
/p
p
Click
t:pagelink page="index"here/t:pagelink
to restart.
/p
/body
/html
ExceptionReport.java
package com.example.tapestry2523.pages;
import org.apache.tapestry5.annotations.Property;
import org.apache.tapestry5.services.ExceptionReporter;
public class
[CONF] Apache Tapestry Extending the If Component
Extending the If Component
Page added by Howard M. Lewis Ship
Extending the If Component
The If component can be made very flexible; its main parameter, test does not have to be bound to a boolean value, it merely has to be bound to a value that can be coerced to boolean.
For example, I'm working on an application that does a lot of Lucene searches, and represents the results as a SearchResult object.
SearchResult.java
public class SearchResultT {
public final ClassT itemType;
public final ListT items;
public final int size;
public final int pages;
public final int firstIndex;
public final int lastIndex;
public SearchResult(ClassT type, ListT items, int size, int pages, int firstIndex,
int lastIndex) {
this.itemType = type;
this.items = items;
this.size = size;
this.pages = pages;
this.firstIndex = firstIndex;
this.lastIndex = lastIndex;
}
public boolean isEmpty() {
return size == 0;
}
}
In a SearchResult, the size property is the overall number of results from the search. The items list is a single "page" of those results to present to the user, consisting of items from firstIndex to lastIndex within the overall set.
In my templates, I have to check to see if the SearchResult exists, then see if it is empty, before we can get to the part that displays the content:
t:if test="searchResult"
t:if test="! searchResult.empty"
. . .
/t:if
/t:if
The first test checks to see if searchResult is not null (null is treated as false). The second checks to see if the search result is empty.
What'd I'd like is for the test to look at the searchResult directly and treat an empty search result as false, and a non-empty search result is true. This is similar to what Tapestry already does for Collections.
This is just a matter of extending the TypeCoercer service:
AppModule.java (partial)
public static void contributeTypeCoercer(
org.apache.tapestry5.ioc.ConfigurationCoercionTuple configuration) {
add(configuration, SearchResult.class, boolean.class,
new CoercionSearchResult, Boolean() {
public Boolean coerce(SearchResult input) {
return !input.isEmpty();
}
});
}
private static S, T void add(
org.apache.tapestry5.ioc.ConfigurationCoercionTuple?, ? configuration,
ClassS sourceType, ClassT targetType, CoercionS, T coercion) {
CoercionTupleS, T tuple = new CoercionTupleS, T(sourceType,
targetType, coercion);
configuration.add(tuple);
}
Inside this thicket of generics and brackets is the code that treats a SearchResult as a boolean: return !input.isEmpty();.
With this in place, the previous template can be simplified:
t:if test="searchResult"
. . .
/t:if
The single test now implies that searchResult is not null and not empty.
Change Notification Preferences
View Online
[CONF] Apache Tapestry Enum Parameter Recipe
Enum Parameter Recipe
Page edited by Howard M. Lewis Ship
Changes (1)
...
{code}
Note the use of literal as the default prefix; this allows us to use the name of the option in our template, e.g. {{t:select blankoption=never .../}}. Without the default prefix setting, never would be interpreted as a property _expression_ (and youd see an error when you loaded the page).
The final piece of the puzzle is to inform Tapestry how to convert from a string, such as never, to a BlankOption value.
...
Full Content
Enum Component Parameter
It's not uncommon to create a component that has a bit of complex behavior that you want to be able to easily control, and an enumerated type (a Java enum) seems like the right approach.
Our example comes from Tapestry's Select component, which has a blankOption parameter that an enum type.
Let's start with the enum type itself:
BlankOption.java
public enum BlankOption
{
/**
* Always include the blank option, even if the underlying property is required.
*/
ALWAYS,
/**
* Never include the blank option, even if the underlying property is optional.
*/
NEVER,
/**
* The default: include the blank option if the underlying property is optional.
*/
AUTO;
}
Next, we define the parameter:
Select.java (partial)
/**
* Controls whether an additional blank option is provided. The blank option precedes all other options and is never
* selected. The value for the blank option is always the empty string, the label may be the blank string; the
* label is from the blankLabel parameter (and is often also the empty string).
*/
@Parameter(value = "auto", defaultPrefix = BindingConstants.LITERAL)
private BlankOption blankOption;
Note the use of literal as the default prefix; this allows us to use the name of the option in our template, e.g. t:select blankoption="never" .../. Without the default prefix setting, "never" would be interpreted as a property _expression_ (and you'd see an error when you loaded the page).
The final piece of the puzzle is to inform Tapestry how to convert from a string, such as "never", to a BlankOption value.
TapestryModule.java (partial)
public static void contributeTypeCoercer(ConfigurationCoercionTuple configuration)
{
. . .
add(configuration, BlankOption.class);
. . .
}
private static T extends Enum void add(ConfigurationCoercionTuple configuration, ClassT enumType)
{
configuration.add(CoercionTuple.create(String.class, enumType, StringToEnumCoercion.create(enumType)));
}
The TypeCoercer service is ultimately responsible for converting the string to a BlankOption, but we have to tell it how, by contributing an appropriate
CoercionTuple. The CoercionTuple identifies the source and target types (String and BlankOption), and an object to perform the coercion (an
instance of StringToEnumCoercion, via the create() static method).
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry ConfigurationUG
ConfigurationUG Page removed by Bob Harner
[CONF] Apache Tapestry Templating and Markup FAQ
Templating and Markup FAQ
Page edited by Bob Harner
Comment:
Renamed, adding FAQ (more or less experimentally) so it will have a decent title in the "Related Articles" boxes
Changes (0)
...
Full Content
Templating and Markup
Main Article: Component Templates
Why do I get a SAXParseException when I use an HTML entity, such as nbsp; in my template?
Tapestry uses a standard SAX parser to read your templates. This means that your templates must be well formed: open and close tags must balance, attribute values must be quoted, and entities must be declared. The easiest way to accomplish this is to add a DOCTYPE to your the top of your template:
!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
Part of the DOCTYPE is the declaration of entities such as nbsp;.
Alternately, you can simply use the numeric version: #160; This is the exact same character and will render identically in the browser.
Why do some images in my page show up as broken links?
You have to be careful when using relative URLs inside page templates; the base URL may not always be what you expect. For example, inside your ViewUser.tml file, you may have:
img class="icon" src="" class="code-quote">"icons/admin.png"/${user.name} has Administrative access
This makes sense; ViewUser.tml is in the web context, as is the icons folder. The default URL for this page will be /viewuser
1
However, most likely, the ViewUser page has a page activation context to identify which user is to be displayed:
public class ViewUser
@Property
@PageActivationContext
private User user;
. . .
With a page activation context, the URL for the page will incorporate the id of the User object, something like /viewuser/37371. This is why the relative URLs to the admin.png image is broken: the base path is relative to the page's URL, not to the page template
2
.
One solution would be to predict what the page URL will be, and adjust the path for that:
img class="icon" src="" class="code-quote">"../icons/admin.png"/${user.name} has Administrative access
But this has its own problems; the page activation context may vary in length at different times, or the template in question may be a component used across many different pages, making it difficult to predict what the correct relative URL would be.
The best solution for this situation, one that will be sure to work in all pages and all components, is to make use of the context: binding prefix:
img class="icon" src="" class="code-quote">"${context:icons/admin.png}"/${user.name} has Administrative access
The src attribute of the img tag will now be bound to a dynamically computed value: the location of the image file relative to the web application context. This is especially important for components that may be used on different pages.
What's the difference between id and t:id?
You might occasionally see something like the following in a template:
t:zone id="status" t:id="statusZone"
Why two ids? Why are they different?
The t:id attribute is the Tapestry component id. This id is unique within its immediate container. This is the id you might use to inject the component into your page class:
@InjectComponent
private Zone statusZone;
The other id is the client id, a unique id for the rendered element within the client-side DOM. _javascript_ that needs to access the element uses this id. For example:
$('status').hide();
In many components, the id attribute is an informal parameter; a value from the template that is blindly echoed into the output document. In other cases, the component itself has an id attribute. Often, in the latter case, the Tapestry component id is the default value for the client id.
Why do my images and stylesheets end up with a weird URLs like /assets/eea17aee26bc0cae/ctx/layout/layout.css?
Tapestry doesn't rely on the servlet container to serve up your static assets (images, stylesheets, flash movies, etc.). Instead, if builds a URL that Tapestry processed itself.
The content that is sent to the browser will be GZIP compressed (if the client supports compression). In addition, Tapestry will set a far-future expires header on the content. This means that the browser will not ask for the file again, greatly reducing network traffic.
The wierd hex string is a random application version number. A new one is chosen every time the application starts up.
This is necessary so that, if an asset changes in place, browsers will download the new version. Because the application version number has changed, it represents a new asset to browsers, who will download the new version, even if the
