On Wed, Dec 21, 2011 at 6:50 AM, Martin Grigorov <
[hidden email]> 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-completionand
https://github.com/ivaynberg/wicket/blob/sandbox/hierarchy-completion/wicket-core/src/test/java/org/apache/wicket/hierarchy/complete/HierarchyCompletionTest.javai 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
Locked
