Ivano, I think his complaint is that you can't configure a page dynamically at run-time. I know we have work-arounds, like RenderBlock and DynamicBlock and such. I think what he wants to do is dynamically re-configure and add components at run-time as opposed to the .jwc/.html/.page. If each of those components was backed by an instance of a class he could create any component and add/remove it to/from a page. He may not understand that Tapestry components are state-less, which means that besides creating instances of a component, it would have to be "attached" to something dynamically.
Maybe he would be happier with portlets. regards, Mark -----Original Message----- From: Ivano [mailto:[EMAIL PROTECTED] Sent: Thu 1/26/2006 7:24 AM To: Tapestry users Subject: Re: tapestry not really component based? gaz jones wrote: >thats not _quite_ what i want though, as its not truly dynamic - thats >including a pre-defined component into the page, not generating a completely >dynamic one... if i have understood your suggestion, i would need to define >every component i ever might need in the jwc or using annotations... > > > From what get of your posts I can't understand what you mean by "not truly dynamic". You suggest substituting: PageLink pageLink = new PageLink(); pageLink.page = "MyGreatPage"; getPage.addComponent(pageLink); // or something similar in the renderComponent. But this looks like an operation to *add* a component to the page, and not to *render* it. To add the component, you simply put it in the page template, in the descriptor or through annotations. And to me this way is better than adding through java code: it lets you change the page composition without touching the compiled code. If you need to create a component to "include" another component than you do it the same way. If you think that this means not being dynamic, you better consider what you need for a component to be actually *reusable*. As I see it there are only in two cases: 1. The component knows its exact internal composition to depend on expected behaviour, or 2. It should be totally independent of possible subcomponents. And this is what you get with tapestry. But maybe I misunderstood your question, and you should consider the following. The renderComponent code: writer.begin("a"); ILink link = getPageService().getLink(true, "MyGreatPage"); writer.attribute("href", link.getURL()); writer.print("Go to my great page"); writer.end("a"); is only written once by the component's developer and the "MyGreatPage" is actually parameterized. As a user you only add the component to a page in the .jwc and use it in the template, passing the destination page as a parameter. And so you need not write any java code for the page or the component you're using. You only need to declare the components that you really make use of, in the .jwc, and this is related to the considerations I previously made. As for the rewind, it's just a different perspective from what you described, and I agree that it takes a little effort to get into. But the component pooling is a useful mean to reduce the application from burdening the system, cause you need not create as many resources, reusing existing ones, and that's what pooling exists for. The difference is that you don't have a "global" page structure that you could navigate to find subcomponents. But this too can be an advantage since you decouple yourself from thinking in terms of how the components are placed within the page. This really helps when you change the page's composition in any way, without being forced to change the listener's code to adapt to the new page layout. Moreover you don't need to actually manage the iteration code to examine dynamic lists of components. The framework creates the loop variable and iterates through the list for you. Ivano Pagano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
