Hi Pedro, I won't be able to review and test this change in the next few days. We use 7.4.0 in our main app and we have 22 usages of <wicket:fragment>. Should be enough to validate the changes. I'll let you know when I'm done!
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Aug 20, 2016 at 6:02 AM, Pedro Santos <[email protected]> wrote: > Hi devs, > > Wicket's container rendering creates a new component for each > wicket:fragment it finds in the markup, and puts it in the component tree. > This process has a few issues and I prose us to simplify it. > > issues: > > - the new component for the fragment can conflict with user's components > since we need a wicket:id for it and we don't have a reserved namespace > - can cause unexpected behaviours like a container with no children testing > true for container.size() > 0 > - adds an unnecessary object in the tree > - adds unnecessary complexity like custom component versioning (we are > setting this component to be not versioned) > - causes misleading exception messages since the fragment markup can be > mistaken by an actual component markup > > My idea it to simple skip wicket:fragment's markup while rendering > containers. The only place we need to load this markup inside the markup > sourcing strategy when providing for a Fragment. > > The implications are to remove FragmentResolver and possible to change > wicket:fragment tag's id attribute from wicket:id to fragment-id or id in > Wicket 8. > > I see this as a non trivial internal change for Wicket 6 and 7, so I worked > on a branch[1] to showcase the idea and to get your thoughts while > resolving WICKET-6219 in wicket-7.x branch. > > cheers, > > Pedro Santos > > 1 - https://github.com/apache/wicket/tree/WICKET-6219-no-fragment-resolver >
