In 2.4 I'm looking at adding more hooks. I'm strongly opposed to protected variables (but not protected accessors). Also, because Tapestry uses interfaces, the path of least resistance is to create a new class that implements the interface, but holds a reference to an instance of the default class (pretty much a JBoss "interceptor").
----- Original Message ----- From: "Martin Schnyder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 20, 2002 3:23 AM Subject: RE: [Tapestry-developer] component definitions > 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 ------------------------------------------------------- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. 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
