Hi,
A while ago a proposal to allow the application spec to "include" other specs defining pages and components was floated (originally by Richard Lewis-Shell, I believe).
The general idea behind the proposal was to provide reusability of the component and page aliases, so that if you have sets of components providing a particular functionality, you won't have to redefine all components in the specification of every single new application, but just include a common file that defines those components.
For a real world example, we have sets of components for building sorting and paging tables, advanced internationalization/localization features, etc. We use those in practically every single application we develop, and having to insert the component aliases and update the app spec when the inner components of a "public" component change would have been extremely tedious.
Fortunately, the combination of Tapestry and Spindle offers an easy and elegant way of resolving the issue: Spindle allows you to easily locate and use a particular "public" component, and Tapestry allows components to be referenced by their .jwc specs (using a class path), rather than by their aliases, which eliminates the need to define aliases for the internal components in a new application specification. In short, this approach neatly circumvents the issue if you do not use component aliases to address inner components within reusable code.
Unfortunately, this solution cannot apply to pages. The reason is that pages can only be referenced by names as defined in the app spec (e.g. RequestCycle.getPage(name) only accepts a page name).
Here is an example of why this is a problem: we have a "date field" component that has a small icon on the side. Clicking on thappcon brings uRequestCyclelgetPage that displays a calendar and allows you to select a date from the calendar (which is automatically entered into the date field when selected, and the calendar window is closed). In order for the "date field" component to bring up the page with the calendar, it must address it by page name. That automatically means that every new application that wants to use this component _must_ define the page name in its app spec.
We are also increasingly moving towards creating "subsystems" consisting of multiple pages that we use together in a group (as one big component) in a lot of different applications. Those subsystems usually have a single "binding" point to the rest of the application (the entry page, for example). Nevertheless, adding a new page to such a subsytem at the moment would immediately break all applications using it, since the new page has to be defined in the application specs of those applications in order for it to work. This is clearly a major problem.
So my question is: Could getPage() be modified to accept paths to page specifications as well, in addition to page names? Are there any reasons not to do that (technical or philosophical)? Is there a better way to achive the goal described above?
If this sounds reasonable, I will add a feature request.
-mb
ObTapestryPlug: An island of sanity in rough web waters.
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
