Up till now I just avoided enclosures and ignored queuing.
But with WICKET-6879 I had to learn that you run into queuing problems
just by using a Border - it's constructor has the only usage of queuing
in Wicket itself.
:(.
Regards
Sven
On 23.04.21 12:40, Andrea Del Bene wrote:
Yes, component queueing exists just to let people open issues for me :-).
I'm also for removing it along with <wicket:enclosure>. To be more clear,
the big problem with these 2 features is that they literally clash with
each other mushrooming tons of problems. In particular, component queueing
has been implemented without a proper refactoring of the internal classes,
which resulted in a code bloat for class MarkupContainer.
So +2 for me.
On Fri, Apr 23, 2021 at 11:48 AM Martin Grigorov <mgrigo...@apache.org>
wrote:
On Fri, Apr 23, 2021 at 11:58 AM Sven Meier <s...@meiers.net> wrote:
x) remove/rework enclosures and component queueing.
Wow!
I've suggested removing the enclosures some years ago but it was voted down
with the explanation that it works 80-90% of the time and this is good
enough. There are many open tickets in JIRA which are for the rest 10-20 %.
I'd vote to remove <wicket:enclosure>!
About the component queueing - I think at the moment only Andrea knows its
internals. I am not sure how many users use it but removing it will
simplify a lot!
Have fun
Sven
On 02.04.21 13:58, Martin Grigorov wrote:
Hi,
Now since we have 9.3.0 released is it time to start thinking/working
on
Wicket 10 ?
Here are few ideas what to break :-)
1) Move to Servlet 5.x, i.e. jakarta.servlet.**
2) Use @Inject + @Named instead of @SpringBean. If everything is
covered
by @Inject we may deprecate @SpringBean in 9.x
3) Depending on the release date we may even bump Java to 17 (it is
going
to be released this September and it is going to be LTS). I expect
Wicket
10.0.0 to be released in 1-2 years from now, so by this time Java 17
should
be mainstream! :-) I know that this is too brave. Most projects still
use
Java 8 for some reason.
Regards,
Martin
