I just merged from master and ran mvn clean install locally and many tests
fail
So I reverted to
commit 3a3e32a597aa312f97cc588a66780783cd0eb9ed
Author: Igor Vaynberg <igor.vaynb...@gmail.com>
Date: Sat Feb 15 21:56:18 2014 -0800
dequeue docs
and the build breaks the same way.
I will debug it.
Martin Grigorov
Wicket Training and Consulting
On Mon, Feb 17, 2014 at 4:48 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> 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
> >>>
>
