Hi,

About stateless ajax behaviors - the Jolira components and behaviors have
been moved to WicketStuff (
https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/stateless-parent)
since two releases. There were two Pull Requests already.

Use them, extend them, polish them and at some point we may vote to merge
them in Apache Wicket ;-)


On Wed, Jun 26, 2013 at 8:41 PM, Cedric Gatay <gata...@gmail.com> wrote:

> Hi,
> I second what Bertrand said. I think having more statelessness in core
> Wicket ajax. I think this is the way to go since it eases deployment of
> "large" instance of our applications. However there is a big pile of work
> for this, so if Wicket 7 is said to be released soon, I guess we'd better
> postpone this.
>
> PS : glad to help, and willing to help more ;)
>
> Regards,
>
> __
> Cedric Gatay (@Cedric_Gatay <http://twitter.com/Cedric_Gatay>)
> http://code-troopers.com | http://www.bloggure.info |
> http://cedric.gatay.fr
>
>
> On Wed, Jun 26, 2013 at 7:29 PM, Igor Vaynberg <igor.vaynb...@gmail.com
> >wrote:
>
> > On Wed, Jun 26, 2013 at 4:20 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> > > Hi all,
> > >
> > > I'd like to discuss where we are with Wicket 7 and what to do next.
> > >
> > > At the moment there are just
> > > 3<
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WICKET%20AND%20fixVersion%20%3D%20%227.0.0%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20created%20DESC%2C%20summary%20ASC
> > >
> > > tickets
> > > with "Fix Version" 7.0.0.
> > >
> > > One <https://issues.apache.org/jira/browse/WICKET-5172> of them is
> about
> > > adding a link for the javadoc at http://wicket.apache.org. Trivial.
> > >
> > > Another <https://issues.apache.org/jira/browse/WICKET-4951> is about
> > > CDI-1.1. John Sarman is helping here. Thanks!
> >
> > i havent had time to keep up with this, be sure we do not lock
> > ourselves into weld...
> >
> > > And the last <https://issues.apache.org/jira/browse/WICKET-5184> one
> is
> > > about the signature of AbstractTree/Model.ofSet(). I don't see a good
> > > solution here, but I have provided a workaround.
> > >
> > >
> > > In the roadmap page there is also:
> > >
> > > Refactor checkgroup/radiogroup to make them non
> > > components<
> >
> https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Refactorcheckgroup%2Fradiogrouptomakethemnoncomponents
> > .>
> > > -
> > > @Igor: do you want to work yourself on this ? Otherwise please give
> more
> > > details how you imagine the new way.
> >
> > im fine with someone else taking this one. the basic idea is to make
> > CheckGroup and RadioGroup non-components because in a lot of cases it
> > is inconvenient to have them wrap some sections. eg when you have two
> > check groups you have to put one inside the other, which is
> > non-intuitive. so the groups are linked by the instance of CheckGroup
> > and RadioGroup objects which can take care of generating unique ids,
> > etc.
> >
> > so instead of code like this:
> >
> > RadioGroup group=new RadioGroup();
> > add(group);
> > group.add(new Radio());
> >
> > we would have
> >
> > RadioGroup group=new RadioGroup();
> > add(new Radio("id", group));
> >
> > makes sense?
> >
> > -igor
> >
> >
> >
> > >
> > > Make CSS class strings used in the framework
> > > configurable<
> >
> https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Makecssclassstringsusedintheframeworkconfigurable
> > >
> > > -
> > > this one is clear. If there are no objections then I'll pick it soon
> > > (unless someone else does it before me).
> > >
> > > I'm going to investigate few tickets about bookmarkable mappers
> > > (MountMapper, MountedMapper, PackageMapper and ResourceMapper) and
> their
> > > handling of named parameters in the path/segments.
> > >
> > > Unless someone has more ideas what can be improved for Wicket 7 I think
> > we
> > > are pretty close to be "feature complete" and we can release a
> milestone
> > or
> > > release candidate.
> > >
> > > I'd like to thank Cedric Gatay, Michael Mossman, Andrea Del Bene and
> John
> > > Sarman for their help so far!
> >
>

Reply via email to