Contributions are always welcome. I prefer to review them before they go
into the tree (ultimately, I may need to maintain them). I'm trying to find
time today (in between laundry and cleaning my house) to review some
contributions from Ming Fang, a frequent Tapestry supporter and contributor,
as well as Jim Birchfield, whose working on a JMX console using Tapestry.
Contributions go into the net.sf.tapestry.contrib-x.x.x.jar in a sub-package
of net.sf.tapestry.contrib. After looking over your code, I can give you
CVS access to Tapestry, or you can mail me the files.
All files will be released under LGPL, and with my copy{left|right|center}.
That's just the rules of the game.
Components are fun, but what Tapestry really needs is more Tutorial
documentation. I'm also thinking of creating a Tapestry Cookbook and a
Tapestry Contributor's Guide.
----- Original Message -----
From: "Adam Greene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 12, 2002 8:24 AM
Subject: Contributing to the project
> Our company is using Tapestry to build website almost
> exclusively now and we are building a great deal of
> components, Renders, Models, etc, that I would like to
> contribute to the Tapestry community. They might need
> some work, we are still learning Tapestry, but we would
> like to contribute as it has helped us. How would I go
> about doing that??
>
> examples of what we have done:
>
> Calendar -- A calendar component that supports
> highlighting of dates, hyperlinks for events, and complete
> color control via style sheets (<name>_calendartitle).
>
> StyleSheet -- a component that traverses the components on
> the page (including subcomponents), checks to see if they
> support the IStyleSheet interface and queries them for
> stylesheet elements, and writes out a stylesheet (it is a
> body=yes component to support embedded styles). Comes
> with classes like IRequestWriter, but for stylesheets.
I'm a little nervous about this design; walking the page component hierarchy
goes against the grain of Tapestry.
It doesn't take into account rule-breaking factors such as the use of
InsertBlock and Delegator.
A better way is to emulate how Body works. The Body instance records itself
into the IRequestCycle before rendering its wrapped elements. They can
therefore find the Body instance when they render, so as to obtain services
from it (such as unique element naming, image preloading and JavaScript
support).
I suspect you are trying to dynamically generate an embedded stylesheet
while you render, correct?
I would implement this using two things: A component that wraps the page,
like the Body component and a helper bean.
Individual components that needs this stylesheet support would obtain their
CSS class attribute (as an informal parameter) from a helper bean. The
helper bean would be configured with the desired stylesheet attributes, and
would locate the wrapping StylesheetProvider component, to negotiate a CSS
class value. It would expose a property to obtain this value, looks
something like:
<bean id="tableClassHelper" ...>
<set-property name="style" value="font-size: big"/>
<component id="table" type="Any">
<static-binding name="element">table</static-binding>
<binding name="class" property-path="beans.tableClassHelper.styleClass"/>
>
> XSLT -- we are currently working on an XSLT dynamic
> compiler component based on the Sun XSLT Compiler, that
> will dynamically compile stylesheets (and cache them) and
> parse XML with them to generate html. (Sort of a stripped
> down Cocoon). We hope to add direct database support for
> pulling out ResultSets as XML and transform it, that along
> with pulling the properties out of a class as XML.
>
> MailTo -- it's a simpel component, but it creates
> a "mailto:"; link. There may already be a way to do this,
> but I didn't find one right off, so I wrote my own,
> besides it's easier to remember that a mailto: is MailTo.
This can now be built easily using the GenericLink component, which gives
complete control over the HTML href attribute (but can still have the
scripting needed by a Rollover component).
>
> Renders:
>
> We created RawRadioPropertySelectionRender so that we
> could use pictures as the values in a PropertySelection.
>
> Models:
>
> We extended the StringPropertySelectionModel to take two
> strings, one for option, one for value.
>
> We are also working on several other models.
>
> --------------------------------
>
> If we have duplicated functionality, like I said we are
> still learning Tapestry, but we would like to contribute.
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
