The BLADE toolkit is a widget set designed to facilitate rapid UI development for web-based applications. Pages in XSL or JSP environments are marked up with tags which are translated by blade into components such as rollovers, tabstrips, content panes, and drillable trees. Each component can be "skinned" into a variety of looks with a minimal amount of effort, allowing true separation of content and presentation.
The XSL version of blade also has some extra functionality to help with static, client-side screen mockups. Since the XSL and JSP versions share the same components and naming conventions, these mockups can be translated into maintainable, easy-to-read JSP pages without the mess of HTML and custom javascript associated with commercial HTML editing packages. Since components are skinnable, JSP development can even start before minor look-and-feel graphical details are worked out.
BLADE is primarily targeted at web-based applications. By making rollovers and drillable trees actual tags, blade provides two advantages over using tools such as Dreamweaver to develop pages. First, your pages are much easier to understand, change, and debug. Second, by linking the same tag to multiple implementations based on browser detection, you can get decent multi-device compatibility (e.g. rollovers can be automatically turned into simple links for text-based devices).
In exchange for this convenience, you need browsers capable of handling CSS and DOM (e.g. not Netscape 4.7) in order for your pages to come out looking good. Additionally, to provide proper support for handheld devices, text browsers, and NS 4.7, you need server-side browser detection. If you are building an intranet application using XSL or JSPs, these requirements are perfectly reasonable. Static websites, however, are exposed to a all sorts of browsers, and by virtue of being static, can't perform browser detection. Besides, what do you need drillable/sortable tables and graphical rollovers for on a static web site, anyways?
BLADE comes in a couple different flavors. The default is the XSL devkit, which contains the XSL widget set, support for client-side mockups, documentation, and tools for editing themes. The important thing to know about this version is that it is flattened - that is, all the server-side and client-side files are combined in the same directory tree. This is great for mocking up pages and testing themes, and can be acceptable for testing a web app, but probably isn't a good idea for production apps.
Other versions of blade come in sets of two files. The first contains server-side files not included as part of the devkit. The second provides a patch to the devkit to get theme information in a server- readable format, and potentially to export the relevant files from the devkit into a pared-down, deployable set.
Blade components generally consist of two parts: the "server-side" and "client-side" portions. This is a bit of a misnomer since in static mockups the browser handles both, but the server side deals with everything involved in creating an HTML page. The client portion deals with everything that happens in the browser after the HTML page has been created. This means that each component set has at least two files: a javascript file for the client side, and an XSL file, java class, or something similar to generate the HTML on the server side.
Themes need to be composed of a css file, js file, and a platform-specific file for passing image urls and flags, such as a jsp, properties file, or xml file. In addition to these, themes for the devkit come with source xml files to help with theme generation. One or more themes together in a directory form what is referred to as a themepack.
Components and themes both need to be imported (similar to the import command in java) before they can be used on the client side. Importing on the server side is platform specifc. Naming is done similar to java classes - the files themes/public/core.js and themes/public/core.css are part of the theme named themes.public.core. The file components/core/widgets.js is part of the component set components.core.widgets. Note that although components and themes are packaged in their own folders by default, there is no restriction on placing them together. If you wanted to create the folder com/yourcompany/projectname/ and stick project-specific themes and custom components there, blade would handle it just fine.
On the client side, the common directory holds the base-level blade js files and a site-wide css file.