On 11/17/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > That might work. > > You'll also need to take into account that components might be > referencing other components - as with the label and the inputText, > the dataScroller and the dataTable.
It's basically kinda lame restricting AJAX updates to just AJAX-enabled components, because then you end up needing to make this knowledge pervasive across all renderers, which is awful. Optimizing some renderers to be especially slick and cool at dealing with AJAX, great. > Eventually, this might be the same problem as with what Adam has described. > > An Ajax enabled component updates on an action another component - and > is bound to this other component via a for attribute. Multiple > components could be handled with grouping, facets allow only one > component as well ;). Those two components would be recreated. > > I don't think this is undoable, but next problem: imagine Ajax enabled > components in a dataTable, dataList, whatever. Yep! Gets tricky. The trick - once you get to things like this - is running a ResponseWriter that drops most generated content, and turns itself on when you hit the right component. > And we all know for a feature/component to really work, it needs to > work in a dataTable, right? How would we go through the lifecycle - > would we step into the necessary iterations in dataTable to go through > the whole dataModel? To come to the actual component representation we > want to use later on? What about saving states here? Are we only > saving states of those component representations we need? > > We can't use findComponent - that doesn't work in dataTable correctly. > That's (or was in 1.1) a spec problem, by the way... There was the 1.1 awfulness where getClientId() on UIData changed depending on the row, which got fixed in 1.2 - is that what you're thinking of? You still can't call findComponent() with a clientId that includes a row number and expect it to find anything. -- Adam
