On Tue, Nov 9, 2010 at 12:03 PM, Sven Meier <s...@meiers.net> wrote: > Hi, > >> an easy example is: >> >> <tr wicket:id="repeater"><td><span wicket:id="first"/> <span >> wicket:id="last"/></td></tr> >> >> now the designer wants tds to have a css class based on some >> condition. you now have to add a webmarkupcontainer to represent the >> td and renest first and last labels into it. the container is there >> purely for the design aspect. > > I have to change some Java code anyway, so why should I queue anything rather > than add() the components into the correct hierarchy right away?
the difficult part is that doing this to complex pages is...difficult. in the example above it is easy to see the two components that need to be renested. but, in complex pages there can be 20 components that need to be renested, and they are probably initially added from a bunch of helper methods that attempted to keep the code clean. so, it may be difficult to find all 20 componets. queuing can make maintenance and refactoring of pages easier. > >> another usecase is introducing an arbitrary webmarkupcontainer just to >> have a div to repaint via ajax. it is hard to do this when refactoring >> a complex page because you have to find all the components that now >> need to be re-nested into the new container. > > Is this a common example? Did anyone ever have to "just repaint a div via > ajax" without having to change much more Java code? What's complex about this > page thus it's difficult to re-parent some of its components? yes, ive had to do it plenty times. ive had to go into pages that were already written and ajaxify them. sometimes a table needs to be updated via ajax, it needs to be wrapped in a container. other times a set of related form fields needs to be updated, its easier to wrap them in a container and update it rather then having to add them one by one from multiple places. > IMHO valid use cases have not been provided yet. we can agree to disagree -igor > > My 2 cents > > Sven > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
