Tapestry components are designed for easy re-use. Most components consist of a specification, a Java class and an HTML template.

Some components may need more; they may have additional image files, sounds, Flash animations, QuickTime movies or whatever. These are collectively called "assets".

Assets come in three flavors: external, context and private.

Components which use assets don't care what flavor they are; they simply rely on the method buildURL() to provide a URL they can incorporate into the HTML they generate. For example, the Image component has an image parameter that is used to build the src attribute of an HTML <img> element.

Assets figure prominently into three areas: reuse, deployment and localization.

Internal and private assets may be localized: when needed, a search occurs for a localized version, relative to a base name provided in the component specification.

Private assets simplify both re-use and deployment. They allow a re-usable Tapestry component, even one with associated images, style sheets (or other assets) to be incorporated into a Tapestry application without any special consideration. For example, the standard exception page makes use of a private asset to access its stylesheet.

In a traditional web application, private assets would need to be packaged separately from the 'component' code and placed into some pre-defined directory visible to the web server.

Under Tapestry, the private assets are distributed with the component specification, HTML templates and Java code, within a Java Archive (JAR) file, or within the WEB-INF/classes directory of a Web Application Archive (WAR) file. The resources are located within the running application's classpath.

The Tapestry framework takes care of making the private assets visible to the client web browser. This occurs in one of two ways:

Copying assets out of the classpath and onto the web site is the best solution for final deployment, since it allows the assets to be retrieved as static files, an operation most web servers are optimized for.

Dynamically accessing assets requires additional operations in Java code. These operations are not nearly as efficient as static access. However, dynamic access is much more convenient during development since much less configuration (in this case, copying of assets) is necessary before testing the application.

As with many things in Tapestry, the components using assets are blind as to how the assets are made visible to the client.

Finally, every component has an assets property that is an unmodifiable Map. The assets in the Map are accessible as if they were properties of the Map. In other words, the property path assets.welcome is valid, if the component defines an asset named 'welcome'.