i think the implementation is good enough to be merged into master now. it supports:
* dequeuing algorithm that delegates to components so subclasses can override (this is how repeaters and borders support it) * support for all major constructs: panels, borders, repeaters * support for auto component hierarchy - they are dequeued and queued up children are placed as the children of auto components - this makes things like enclosures trivial to implement where as before they were fairy complex * performance comparable to adding, still some room for improvement with clever/efficient data structures maybe, but i dont think its needed... todo: * fragments - should be trivial, possibly as trivial as letting it implement IQueueRegion * check markup inheritance works on pages, panels, fragments. * examples * update to the guide -igor On Fri, Feb 14, 2014 at 8:36 AM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > i am reworking the implementation a bit to properly support borders > and repeaters by delegating to components...will check it in when i > have it working... > > -igor > > > On Fri, Feb 14, 2014 at 7:26 AM, Martin Grigorov <mgrigo...@apache.org> wrote: >> On Mon, Feb 10, 2014 at 6:01 PM, Igor Vaynberg >> <igor.vaynb...@gmail.com>wrote: >> >>> 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. >>> >> >> Basic usage of Border is now supported. >> I have added a test with nested Borders and it fails. >> Please check >> org.apache.wicket.queueing.ComponentQueueingTest#dequeueWithNestedBorders >> >> >>> > >>> > 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. >>> >> >> I've added ComponentQueue2 based on HashMap with the same initial capacity >> (8) and >> loadFactor 1. >> >> wicket-util has MicroMap for 1entry and MiniMap for fixed size entries but >> it doesn't use hash function so it iterates over the entries as we do over >> the array in ComponentQueue(1). >> >> With ComponentQueue2 the map will start with capacity 8 and will double >> when the ninth is to be added, as in ComponentQueue. But it won't shrink >> until it becomes with size 0. >> org.apache.wicket.queueing.ComponentQueueingPerformanceTest gives almost >> the same results for both impls here: >> add duration: ~2500 >> queue duration: ~2400 >> >> memory wise Intellij IDEA reports: >> - with ComponentQueue: max memory 88Mb >> - with ComponentQueue2: max memory 154Mb >> >> so ComponentQueue is a winner here. I've added ComponentQueue2 just in case >> someone wants to try to optimize it >> >> >>> >>> -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 >>>
