On Wed, Dec 21, 2011 at 6:50 AM, Martin Grigorov <[email protected]> wrote: > Hi, > > Let discuss (again) what will be included in Wicket 6.0 so we can > schedule what and when will be implemented. > > Here is how I see it: > - use JQuery as backing library - already in master/trunk > - rework Wicket Ajax to use event registration instead of inline > attributes (like onclick, onchange, ...) - already in master, needs to > be polished > - add support for resource grouping/bundling and dependency management > - already in master > - rework IHeaderResponse to work with HeaderItem to make it easier to > render new elements/attributes - already in master > - add support for @javax.inject.Inject - in master, but may need more > work. Need to decide how much will be changed here > - add wicket-cdi - only if JBoss publish CDI jars in Maven central repo
cdi and weld jars are in central. seam jars are not there yet. we use seam for cross-container conversation management which is not pat of cdi 1.0 but is coming in 1.1. if seam jars are not there yet before we are ready for M1 i can put the weld-specific code into the distro. that way we can at least support cdi backed by weld which will be the majority of cases anyways. > - component queuing - @ivaynberg: shall we include that or it is not stable ? its not stable yet. as i was implementing component queuing i realized that by itself it is not enough. sure, we can dequeue components, but it doesnt solve the myriad of other problems we have - namely things like borders and enclosures. what i am trying to do is to make sure that if a queued component happens to be inside an enclosure or another resolver-based component it is dequeued into that component instead. resolved components will no longer be "auto", they will be kept in the hierarchy across requests. this will finally solve the enclosure+form components and other headaches introduced by auto components. however, bringing resolvers into the dequeuing process poses two complications: * where as before dequeuing was done by iterating queued components and finding them in markup, because we are now also resolving components we need to iterate the markup instead and either dequeue or resolve * IMarkup and resolvers are not exactly built to work with components that are kept across requests i am going to get Juergen's help over christmas to try and resolve this. i think if we do crack this it is going to make a lot of things much easier and remove a lot of surprises users encounter with resolvers and auto components. also, if this work we can consider making add() work like queue() in wicket 7. a very rough impl is here: https://github.com/ivaynberg/wicket/tree/sandbox/hierarchy-completion and https://github.com/ivaynberg/wicket/blob/sandbox/hierarchy-completion/wicket-core/src/test/java/org/apache/wicket/hierarchy/complete/HierarchyCompletionTest.java i will probably move the branch over into our git repo soon. -igor > - before RC1 rename packages so there are no overlaps in different > jars (OSGi friendly) > > This is my list. > > I suggest to release M1 sooner to get more feedback earlier. > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com
