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. > > > > 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. > I find BorderBehavior as a nice demo - it shows how to have a behavior with its own markup It is actually very old. Its previous name is MarkupComponentBorder. My assumption that it is not used is because I don't remember anyone talking about it - neither bug reports, nor questions for clarifications in users@. Its only usage in Wicket code is org.apache.wicket.examples.forminput.BeforeAndAfterBorder, so I suggest to move it to wicket-examples instead of totally nuke it. BorderPanel is since 1.5. Juergen introduced it to show how to use a Panel instead of a Border when there was a discussion whether to remove 'final' from MarkupContainer's add/remove/replace/addOrReplace methods because Border needed to delegate all of them, not just add() Since then I don't remember anyone talking about it > > > > 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 >
