Tapestry component deficiencies

[Beat Hoermann <ho...@freesurf.ch>]

Tapestry web components are made of Tapestry jwc-components and Tapestry page 
components. The Tapestry jwc-component comprises all the logic and resources 
related to a component specification whereas the Tapestry page component 
comprises all the logic and resources related to a page specification. A 
simple Tapestry web component is just made of a single jwc-component whereas a 
complex Tapestry web component, such as the inspector button component in 
Tapestry's contrib-library, is made of several jwc-components and several page 
components. Of course, both types of components may themselves be made of 
other, nested, Tapestry components.

So far so good. For now, let a "multipage web component" be a web component 
that consists of more than a single page, that is, in Tapestry's world, a web 
component that is made of a jwc-component and at least one page component. 
Tapestry's inspector button component is a multipage web component and there 
are a few more in the contrib-library.

In Tapestry it is not possible to declare a multipage web component as a 
single unit. (However, you can *treat* a multipage web component as a single 
unit.) This is evident in the application and library specification files 
where the paths to the component specification *and* to the individual page 
specifiations have to be listed. (See, for instance, the page entry of the 
Inspector page in the "Contrib.library" file.)

Consequently, Tapestry has no namespace for a multipage web component. 
Tapestry only knows about application namespaces and library namespaces. In a 
i18n capable multipage web component, i.e., a web component that supports 
different languages, it is not possible to centralize any messages shared by 
the individual pages other than putting these messages in a so 
called "namespace message catalog". By doing this, the messages are seen 
application wide or library wide but not web component wide. To be concrete: 
Assume there is a need to make the inspector button component multi-language 
capable and assume that there are messages that are shared between the 
individual pages and the local sub-components of the inspector button 
component. Then putting these messages into the contrib-library's namespace 
message catalog makes them visible to all other components contained in the 
library not to say of the potential risk for a nameclash with a message key 
already defined by another component.

In Java, libraries do not hava a namespace but components have one: Components 
in Java consist of one or more packages. Tapestry itself is, for instance, a 
Java component where all names are virtually prefixed by 
the "org.apache.tapestry" literal character string.

Maybe replacing the library namespace concept by a web component namespace 
concept would help clarify the situation in Tapestry.

I use Tapestry 4.0.2. I do not know if this issue is addressed in Tapestry 5 
(aka Tapestry IoC). I even don't know if this is the right forum. Therefore, 
any comments on this complex topic are highly appreciated.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org