Hi Pablo,
The Table component does what you are asking for in a number of ways. It may be an overkill for your purposes, but it does demonstrate how it can be done neatly. It is not yet in a released (it will be in rc1, I believe), and it is still in the process of being documented, but you can see its code in the CVS (http://sourceforge.net/cvs/?group_id=4754 -- there is Web access).
Have a look at the following classes:
net.sf.tapestry.contrib.table.model.ITableColumn -- an interface that returns IRender for the rendering of two separate parts of a column (header and value)
net.sf.tapestry.contrib.table.model.simple.SimpleTableColumn -- an implementation of ITableColumn that uses a component on another page to generate an IRender for the header (note that IComponent extends IRender)
net.sf.tapestry.contrib.table.components.inserted.SimpleTableColumnComponent -- the component used by SimpleTableColumn to render the column heading. Note that it includes a link that modifies the state of the table model as well (changes the sorting state), so there is demonstration of a reverse link between the IRender and its caller.
tutorial.workbench.table.LocaleSelection -- shows in a number of ways how Blocks can be used effectively to the same effect. For a good demonstration of what can be achieved without much effort, you can download the version from the CVS and run the tutorial.
In conclusion, there is are very good reasons why pages have a static structure in Tapestry -- this allows pooling of different instances that can be interchanged freely, and avoids the hefty initialization process for the components when a new structure is established (e.g. the setting of what the current page is down the chain. Also it must set its bindings and listeners every time a render is required, rather than just once at load as it is at present). In other words, the performance cost of making something like Tapestry completely non-static would be significant. There are other reasons as well, but I am sure Howard can expand on those.
Basically, you _can_ achieve a sufficently dynamic interface with the current structure. I am sure that that can be eased a bit by building some additions on top of Tapestry in the future, but you should have pretty much everything that you require now, and I believe the Table proves that conclusively.
If there is are problems with that approach, feel free to ask -- I will be very happy to help.
Best regards,
-mb
"Pablo I. Lalloni" <[EMAIL PROTECTED]>wrote:
I thought that one out, but I see it dificult to extend in the
future...
As far as I undestand (which is not much) the Blocks definitions must
be on the template of the component so... adding support for some
class involves adding a block definition to the template and some
association in some other place between the class and the Block name.
It would be great if in place of adding a Block to the template of the
component, you could add another independent component and the
association between the new component and the class.
So the component could be on a predefined not-to-be-touched library,
and when you must add support for some class in some application you
can just build the new component and register the association.
Do you see any way to accomplish this?
The ability to programatically add components to a page/component (like
you can do with Swing or CLX) would be great for building really dynamic
interfaces with Tapestry.
Is there a way to support this on Tapestry?
--
Saludos,
Pablo mailto:[EMAIL PROTECTED]
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
