On Wed, Nov 10, 2010 at 1:05 AM, Carl-Eric Menzel <cmen...@wicketbuch.de> wrote: > On Tue, 9 Nov 2010 12:16:00 -0800 > Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > >> 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. > > I can see how it might make it somewhat easier, but it seems to me that > one is treading on rather thin ice.
well. the thin ice part of the argument remains to be proven. when can it cause problems? how about some practical examples? > And speaking of these helper methods: Maybe it's my increasingly > functional style coming from some exposure to Scala, but I really hate > it when these methods add stuff behind my back to anything else than > the component they're returning. you are explicitly telling it to add things behind your back. the queue() method does not replace the add(), its an addition. it operates on a container, so it returns the container back - that makes sense. >> 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. > > But wouldn't such a page be a prime candidate for a proper refactoring > anyway? I'm getting a "quick & dirty" feeling. not at all. adding three or four ajax-zones into an existing page does not warrant a refactor, nor would there be anything to refactor. there was no need for these things before, they are there purely to facilitate the new requirement of making something ajaxy. -igor > >> > IMHO valid use cases have not been provided yet. >> >> we can agree to disagree > > Certainly, especially since you do make some valid arguments. > > Carl-Eric > www.wicketbuch.de > > --------------------------------------------------------------------- > 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
