On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > > On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > > > i just pushed my new idea into sandbox/component-queueing-2 > > > > the way this works now is instead of doing it in onInitialize() and in > > onConfigure() and all the other places dequeuing now works progressively. > > upon a change (container.queue() or component.add()) a dequeue will be > > tried. > > > > it even works well with resolved components like enclosures. for such > > components the markup of page/panel is traversed in onInitialize() and all > > auto components are placed into the queue. later as components are > > added/queued these components will be placed into the correct place in the > > hierarchy. if queue() is used children of these components will be placed > > under them in correct hierarchy place. this is a big win for using queueing > > over adding. > > > > repeaters also work. the repeater items themselves have to be added to the > > repeater, but item's children can be queued. this is not a problem since > > items are mostly added by framework classes. > > > > Borders do not yet work mainly because i havent tried to make them work. > > the tricky part there is to keep the border and BorderBody queues separate. > > > > I've added some code to support it but it needs more work. > See my response to the commit notification email of my changes. > > Also we have BorderBehavior and BorderPanel. > I think (almost) no one uses those but they exist.
imho we can nuke these two things from 7. they dont look very useful. probably added just because we could. > > InlineEnclosures do not yet work because the code for figuring out the > > value of the child attribute is really convoluted for the simple thing its > > supposed to do and i didnt bother parsing it. Should be very similar to how > > EnclosureHandler works. > > > > Done. thanks. > > the performance is good. there is ComponentQueueingPerformanceTest with a > > disabled test. give it a go and let me know the results. on my box queuing > > had under 10% overhead, which is acceptable. I also have some ideas on how > > to optimize that further by trading cpu for a bit more memory, but not sure > > > > In my branch on this topic I used HashMap instead of array. The lookup is > faster. Not sure how much memory overhead there is. yeah. havent had time to profile it yet. there are some memory efficient hashmaps floating around, maybe we can adapt one of them. -igor > > if its needed since the overhead is low and because its only present when > > queuing is used. also the measurements are not too accurate because most of > > the time is spent initializing and tearing down a WicketTester instance. > > > > memory overhead is also low, two slots (one of which can/should be > > converted to a flag) are added to MarkupContainer. > > > > see ComponentQueuing test for some examples. i would appreciate some help > > getting Border and InlineEnclosure working if someone has time. > > > > look over this and lets discuss if/when we should merge it into master. > > > > -igor
