Hi Valerie, I would suggest taking a look at the BeanEditor and related components + services. That would be the best starting place for something like this, in terms of understanding how a component can components at runtime that were unknown by the original component authors.
Cheers, Robert On Apr 15, 2013, at 4/156:06 PM , Valerie Wagner <valerie.wag...@sri.com> wrote: > > I'm just getting started with learning Tapestry and am struggling a bit with > the "static structure, dynamic behavior." We are developing an application > that is going to allow plugins from third-parties. For example, the plugins > will each provide a capability and have their own settings. We want each > plugin to be able to provide its own Tapestry Component to allow the user to > configure the plugin. For example, I may have a page that renders all the > settings of all plugins (or perhaps the user selects a plugin from a list & > views on that setting). > > I'm doing as much reading as I can through the documentation and examples, > but it's just not clear to me how to structure this. If my application > doesn't know the complete list of Components ahead of time, I haven't thought > of a way to dynamically render them. I've been looking at delegates, form > injection, filtering...but none of it seems appropriate to me. > > I'd appreciate any help or thoughts on this. What I need is something along > the lines of: > > foreach plugin in our list > render the "settings" component for that plugin > end > > or > > render the "settings" component for plugin with id X > > thanks, > Valerie > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
