I have the same problem when I run my object model which (tapestry components bind their values to) through external validation. I validate the object model and have set of errors and if the errors are inside a component that is in a loop its very hard to attach that error to it. To resolved this I had to change the field trackings in the validation delegate to get around the fact that I could not access looped component s state in a listner method.
There is just a problem that things dont work the same way in loops as they do in the rest of the page. Its a real "gotcha" and people should be made to be aware of it when they use the framework. Dont get me wrong I love tapestry. There are some really cool features, and tapestry 4 blows everything else away like it. I chose it for the lastest project at my work and other than the loop problem everything is great. I have also written a sample application that I will realease for people to see as an example of a tapestry 4 project pretty soon that includes integration with ajax. On 26/01/06, gaz jones <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > -- d-_-b \m/(>_<)\m/ (9ò_ó)-o(@_o)
