Another way around this is XML entities, but I am a firm believer in
including chunks of files. We have a rough design for doing the same with
JWC files so that common component configurations might be reused.
-C
|--------+---------------------------------------------->
| | Mind Bridge |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 07/01/2002 09:16 AM |
| | |
|--------+---------------------------------------------->
>--------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: [Tapestry-developer] Getting pages by jwc spec rather than by
name |
|
|
>--------------------------------------------------------------------------------------------------|
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
