I implemented a little extension to Tapestry myself that does part of what
Christian suggested, although it's just for some part of page/component
configuration. I have to mention that we use Tapestry (also) for VoiceXML
applications, which gave us some special requirements to the component
model. We mostly use pages (or groups of pages) as components. These pages
can be used in several parts of an application but with different
configuration. The configuration that changes is mainly the value of a
property (which is the name of a properties file with further configuration
data) and the name of the class for a page.
Our goal was to use a library of pages/components in several applications.
We wanted to use the pages/components with this little customization but
without copying/modifying the templates and .page/.jwc files.
What we did is an extension to the .application file (a .application_ext
file) that contains this customization data. It can contain entries like:
<page name="ApplicationPageA"
specification-path="... /LibraryPageA.page"
class="ApplicationClassA">
<property name="pagePropertyA">value</property>
<component-alias type="ComponentB">
<property name="componentPropertyC">page local value</property>
</component-alias>
</page>
<component-alias type="ComponentB">
<property name="componentPropertyC">application global value</property>
</compone
Here ComponentB has a property value assigned that is set in all pages that
use ComponentB (in the second definition). ApplicationPageA uses ComponentB,
but assigns a special value for componentPropertyC (page local definitions
have precedence). ApplicationPageA also uses a different class than the page
from the library (LibraryPageA). This way, ApplicationPageA somehow inherits
LibraryPageA but uses a subclass of its Java class and sets its own
initialization values of its properties.
The integration of this into Tapestry required some modifications to the
DefaultSpecificationSource and the Namespace classes.
I don't show this to propose it for an addition to Tapestry. It is probably
too specific to the needs we had for VoiceXML generation. I only want to
show what people do with Tapestry and that Christian is not completely alone
with his ideas.
BTW, because Tapestry is open source and because of its good design, it is
possible to integrate extensions like this. Although, it makes it a bit
difficult because so many classes are not made for subclassing. Classes like
DefaultSpecificationSource or DefaultTemplateSource invite to implement your
own (non-default) subclasses. But because almost all variables and some
important methods are private, you have to make copies of these classes
instead of adapting them in subclasses. It would be helpful if less
variables would be private. If DefaultTemplateSource would have a
(non-private) method that just returns the template extension ".html", it
would be easier to implement a template source subclass for other templates,
like ".vxml".
Regards,
Martin Schnyder
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Christian Sell
> Sent: Donnerstag, 19. Dezember 2002 14:35
> To: [EMAIL PROTECTED]
> Subject: [Tapestry-developer] component definitions
>
>
> Hello,
>
> I would like to bring up again the point about component
> configurations. As far as I remember there was no final
> answer.
>
> In Tapestry component configurations have to be repeated for
> every page and component which embeds the component.
> Moreover, all components have to be assigned type aliases in
> the application file (I am not familiar with the workings of
> libraries yet).
>
> This is in contrast with other component systems I have used,
> among them tiles (BTW, if looked at solely from the
> standpoint of presentation components, the tiles model is
> quite good. What it lacks is behavioral componentization). In
> those systems, component configurations are/can be kept in
> dedicated registries from where they can be referenced by any
> other component/page in the application. This allows reuse of
> component configurations, and possibley more effcient
> cacheing than is done today by tapestry. Of course it is
> conceivable to maintain nested registry namespaces, even down
> to the level of the individual page/component.
>
> I also dont quite see the need for the type alias definition.
> Why not reference components by the complete path to their
> location, as is done for java classes? BTW, I also see
> WebOGNL doing it this way (e.g. component
> id="/path/path/name").
>
> Does anyone else think it would at least theoretically make
> sense/be possible to introduce these items into tapestry?
>
> thanks,
> Christian Sell
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Geek Gift Procrastinating?
> Get the perfect geek gift now! Before the Holidays pass you by.
> T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
> _______________________________________________
> Tapestry-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
