these things are usually added after the fact, which means you have to add the container then go find all the children that should be added into it and change the parent of the add() calls. just like any time when you have to insert a container into existing hierarchy, but one of the primary usecases is to do what the enclosures do.
having these containers in code adds a lot of noise. some uis are prone to having a lot of these. eg when you hide a form component you also want to hide some static help markup. without enclosures this means having an extra container for each form component with dynamic visibility. enclosures were born as a practical solution to these frustrating problems. if they are broken they need to be fixed, but removing them is not an option i dont think. -igor On Mon, Jun 17, 2013 at 10:32 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > By pain what do you mean ? More code to write or some other problems ? > > What to do with these tickets ? I can close all but one as duplicates and > link them ... > > > On Tue, Jun 18, 2013 at 3:12 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > >> even though wicket:enclosure doesnt work for every single situation >> out there it is still immensely useful because it works for 90% use >> cases out there. so -1 to deprecate. in fact, the reason we introduced >> it in the first place was because adding EnclosureContainer-like >> components in code was a pain. >> >> -igor >>
