Hi Martin,

>new Tree impl

I'll still have to do minor cleanups and javadoc, but no api changes.

>WICKET-3927 I think this one can be closed.

Agreed.

>WICKET-2128 I agree that ${label} should be used

IIRC the reason for using ${input} is that the label isn't necessarily set on the component.

>WICKET-3317 introducing Optional

I'm -0 on this, IMHO the benefit of optional doesn't justify such a big api change.

I have two or three other things I'd like to tackle in the next weeks, but they are no reason to delay a first 6.0 milestone.

Regards
Sven

Am 20.02.2012 20:53, schrieb Martin Grigorov:
Hi,

Let's discuss the open tasks for Wicket 6.0.

 From the roadmap:

- component queueing
@ivaynberg: any progress here ? I'm OK to skip this for later release
if it is too much work.

- javax.inject.Inject for Guice and Spring
I think the current impl is enough for now so I'll close the ticket.
If you think more has to be done then please comment in the ticket and
we will reopen it.

- new Tree impl
Great work, Sven! Both the impl and the examples look very good.
Is there anything else to do ?

- CDI
seam-conversation-*** modules are still not available in Maven central repo

- renaming for OSGi
Does anyone have an idea how many packages should be renamed ?
Some people say that a package should have its module name in it (e.g.
o.a.w.core.**). Other people say that we should rename just the
packages which exist in two or more modules.


 From Jira:

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+WICKET+AND+fixVersion+%3D+%226.0.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide

- WICKET-3927 Use a resource loading lib to setup order for processing
ajax response fragments
I think this one can be closed. It seems the current impl serves well.
Objections ?

- WICKET-2128 StringValidator error messages erroneously mention input
instead of label
How to deal with this ?
I agree that ${label} should be used but there is a comment by Igor
saying that this has been discussed before and core devs agreed to use
the raw value (input).

- WICKET-4026 Consider moving registration of IMarkupFilter
implementations to I***Settings
I think we should keep it as it is now. There is some special logic
about the order of the added IMarkupFilter which may break user apps
if the order is not correct. So it is better to keep it harder to deal
with those.

- WICKET-3317 Investigate whether introducing Optional will make life easier
I think this will be an improvement if used for all AjaxFallback***
components to indicate that AjaxRequestTarget may not be available.



Please comment what of this should and should not be done. If you have
a vision how to do it, even better.
I'd like to release a milestone as soon as possible. I'm aware of few
people experimenting with 6.0-SNAPSHOT and so far there are no major
issues. It would be good if we get more feedback with an official
6.0-M1.


Reply via email to