Hi, As Howard has said, DynamicBlock is dangerous, Tapestry depends on a static component structure, The current DynamicBlock was designed based upon my expectation of a dynamic component structure a la WebObjects.
I have an idea for an updated DynamicBlock based upon a custom template/specification resolver delegate whcih will generate a page containing a Block wrapped around the requested component which should make DynamicBlock safe for Tapestry. Mike On Thursday, December 29, 2005, at 01:19PM, Stephen Todd <[EMAIL PROTECTED]> wrote: >I have been looking at DynamicBlock (by Michael Henderson, >http://www.behindthesite.com/blog/C1931765677/E1630021481/). He seems to >have been able to work something out that works. I will have to do some >testing, but something like his will definitely work. > >The possibilities of drop in frameworks I think is very possible and >valuable. Utilizing hivemind, I could design an app where I drop a jar >in a directory and suddenly a bunch of new functionality is made >available to the application. The jar would contain code and functionality. > >The idea is to have a bunch of "areas" in an app that provide HR >functions, Accounting functions, Project Management functions, etc. You >could put each of these in a jar and drop them in. You could probably >work it out without having to restart. The user then could choose from a >list the areas to add, incorporate and configure. The areas could >include functionality to enhance the relationships between each of the >areas. > >The problem (according to the current paradigm) is that the base app >would have to know about all the different components ahead of time. But >with the code in DynamicBlock and after looking through tapestry's >component loading code, I think I should be able to come up with a >solution to fit my needs. > >The nicer solution to this would be to allow ognl expressions for the >type. This might be easier to patch than to make the component. I'm >looking into both. > >-Steve > >Robert Zeigler wrote: > >>What you are trying to do is a no-go in tapestry (dynamic specification >>of the component): tapestry is static structure, dynamic behavior. >>BUT, you can still achieve the desired affect, and the trick is, in >>fact, to use block/renderblock. You always render a block component with >>a render block component. However, 1) the block to be rendered can be >>obtained from virtually anywhere, and 2) the block to be rendered can >>/contain/ virtually anything. >>So, wrap your component(s) to be rendered inside of named blocks. Then >>use renderblock to pick the appropriate block to render. >> >>Something like: >> >>blah.html: >> >><div jwcid="@RenderBlock" block="ognl:block"/> >> >>blah.java >> >>public Block getBlock() { >> IPage page = getRequestCycle().getPage(lookupAppropriatePageName()); >> return page.getComponent(lookupAppropriateBlockName()); >>} >> >>someotherpage.html >><block jwcid="[EMAIL PROTECTED]"> >> <!-- put here your html, or your custom components, or whatever the >> heck you want... this is where the "dynamic" portion would go... >> whatever you were trying to specify as a component type string >> before. >> --> >></block> >> >>So, you have only one "application page", which is fine. >>Now any other "pages" you create simply use BasePage as their class, >>and they serve only as component holders. >> >>Voila. Static structures, but dynamic content, and no >>if's required. >> >>Robert >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
