ivano: i think you slightly missunderstood my example, maybe it wasnt particularly clear. i would not be developing a componet to display a link that i would like to use in a page, i would be developing a component that inherits from AbstractComponent and needs to have links to other pages inside of it. now i would assume that i could use the components that have already been written to do this -> PageLink for example but i cannot because they cannot be instantiate directly in code. so i am forced to repeat functionality that PageLink provides within my own component. which leads me to think, this is not a true component based framework.
imo that is a major disadvantage, as it prevents you from dynamically creating components that are made up of _other_ components when you inherit from AbstractComponet - that is a REAL pain. and something you can do easily in other component based frameworks. as for the rewind phase... its not a matter of not thinking about the page in terms of how the components are placed in the page, its about accessing looped components at rewind phase which is a very obvious thing to want to do that you just cant easily do it. clearly im wanting something that just isnt there at the moment - but what i want to do is not unreasonable, nor is it unusual... and i cant see why everyone else wouldnt want to do it too... On 1/26/06, Mark Stang <[EMAIL PROTECTED]> wrote: > > 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] > > > >
