> > Phew. I wonder if that makes any sense?!? Regardless, the required > > parameter problem is not the big issue here IMO - the bigger issue is > having > > a way to elegantly construct/change bindings during the life of a > component. > > I think the real issue is how to elegantly achieve your goals, which is to > have components imported from another page intergrate into the rendering > page. Copying bindings is a solution but it is problematic in the greater > scheme of things. > > It seems to me that there must be some way that you could have components > inside a Block bind thru the block, to the page (or component) that contains > the InsertBlock. > > Perhaps InsertBlock should set a property on the Block ... let's call it > wrappingComponent. > > Components inside your Block could bind parameters to wrappingComponent.foo. > > This is stil awkward compared to normal use of components. In this design > you are saying "this component can be used on a page that provides the > necessary properties", whereas normally a component can be used anywhere, > just by binding its properties correctly. But it is a start. What do you > think?
I like the sound of this - I actually came up with something similar yesterday while trying to explain the problem here. But I can't quite see the end-to-end answer yet - in particular relating to 'output' parameters especially combined with inherited-bindings (which is where the binding copying code I am currently using gets messy). Can you give me an example of how this would actually look? Thanks for your thoughts/help, R _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
