Johan Compagner wrote: > >> >> * alternate parents: in 2.0, there was a possibility to define an >> alternate >> parent to add child components. > > > isn't this transparent resolver? >
No, it's not. It's allowing users to add child components to a 'blackbox' component directly, while they are actually added to some internal container (that you don't want to expose). One option was to allow the 'add()' to be overridden, but that seemed to be unacceptable. The other was to have an interface IAlternateParent that was considered within the add(). That was what 2.0 offered. Is there any chance we get something similar in 1.4 ? Johan Compagner wrote: > >> >> * markup fragments: in 1.3, calling renderComponent() (for Ajax requests) >> fails if no markup is associated with that component or the direct parent >> of >> that container. In 2.0, this was no problem (I suppose because of the way >> markup fragments were assigned to components) > > > why would you call render() on something that has no markup? and > then an error shouldn't be thrown? > I guess in 2.0 this was an impossible situation. There was always markup > attached. > because that was already done in the constructor. > I did not explain correctly the problem: renderComponent() fails for components that are dynamically created and contained in a RepeatingView. Since MarkupFragmentFinder tries to locate a markup element with the id of the component, it fails to locate any markup for these components. This occurs if we want to render separately a single row in a table or a single button in a dynamically constructed menu. This was possible in 2.0, but it's not in 1.3. For now, we have to render the whole table or the whole menu to refresh a single line or button. Would it not be nice to allow this in 1.4 ? Jan. -- View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14390821.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
