On Thu, Jan 20, 2011 at 11:50 AM, Jim Pinkham <pinkh...@gmail.com> wrote:
> I still don't think it's necessary, and wonder if it might actually be > counter-productive to have more than one way to learn for new adopters. If > it goes forward, I don't suppose there's much precedent for taking > something > back out, is there? > This is the key for me. I make my living off of teaching Wicket classes. New people to Wicket always make mistakes with models and a few other things. But after the first morning of class, they almost *never* have a problem with component hierarchies. BUT - if we add two ways of building a hierarchy, and one of them is a little "magical", then it gets difficult. It's too bad we don't have mixins in Java - it would be nice to be able to have this feature as an entirely separate jar that could be added. I guess you could do it now, but rather than calling #queue(compToBeQueued) on your component, you'd have to use something like ComponentQueue#queue(component, compToBeQueued). That could store it in metadata like the current implementation (if it hasn't changed since the last time I looked at the code), and then an onbeforerender listener might be able to de-queue everything. I'd have no problem with it being an "add-on" that isn't in the core Component. > What a difficult discussion to have over email - I'm in the -1 camp on this > overall, but I think I do appreciate the admirable motive to innovate, so I > hope the committers will give this serious consideration and then chuck it > in the bin where it ... no, just kidding, ;) and then make a fair > decision. > We never dismiss things off-hand, and will give it consideration. But we have to consider both new and advanced users. I just don't think there's enough of a use-case requirement for it to justify the confusion that I *know* it will cause. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
