Re: component definitions

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/