> I am confused.
We already found what we want, thank you.
Sven
Am 04.01.2018 um 10:57 schrieb Martin Grigorov:
Hi Korbinian, Sven,
I am confused.
Both of you say that jQuery is not a problem and few sentences later say
that jQuery prevents the usage of defer/async...
I am sure you will find your ways to do what you want!
Martin
On Thu, Jan 4, 2018 at 11:06 AM, Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:
Hi Martin,
i think we dont see jQuery as problem, but mere the current integration of
all wicket JS and ajax and the depending on it. Its more an adaption to
current standards, where old IEs and other quirks in browsers aren't needed
anymore - so to say.
Currently wicket has a real big problem with first page impression and
high speed rendering on mobile devices as all JS resources are limited by
wicket in not beeing able to get deffered or even async'd. Ideally the
wicket JS integration not only should accept defer but be built around full
async into the JS part - that however would not be possible with jQuery as
this one only allows defer at max as the ordering matters here...
Best,
KB
----- Ursprüngliche Mail -----
Von: "Martin Grigorov" <mgrigo...@apache.org>
An: dev@wicket.apache.org
Gesendet: Dienstag, 2. Januar 2018 12:43:41
Betreff: Re: 8.0.0 blockers
Hi,
1) one can always replace the version with JavaScriptLibrarySettings
2.x is used as default because most jQuery plugins are not migrated to
3.x,
JS folks moved to more modern JS solutions (React, Angular, Vue, ...)
2) wicket-ajax-*jquery*.js is named this way because it depends on
jQuery!
One can always implement the Wicket.xyz JS APIs on top of vanilla JS,
Dojo
2.x, Angular 5.x, ... And use it via
JavaScriptLibrarySettings#setWicketAjaxReference()
Such alternative implementation can be introduced at any version of
Wicket.
But what exactly is the problem with jQuery (in Wicket) ?
Why its event listeners do not work for this use case ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Jan 2, 2018 at 12:54 PM, Sven Meier <s...@meiers.net> wrote:
Please take a look at the pull request:
https://github.com/apache/wicket/pull/253
As you can see, there are many places that have to work together - do
you
see a good way to make that configurable?
I'd prefer to support a single solution only:
addEventListener() instead of jQuery "domready"/"load" and maybe a
central
hook allowing to defer all JavaScript resources (perhaps there's already
one I'm not aware of).
This way users can defer JavaScript if they want to, but we don't force
it
on everyone (e.g. if they still need JavaScriptHeaderItems).
IMHO moving the framework away from jQuery is the right direction anyway
(see http://youmightnotneedjquery.com/), but perhaps Wicket 8 (or
shortly
before the 8.0.0 release) is not the right moment for it.
Regards
Sven
Am 02.01.2018 um 11:34 schrieb Martin Makundi:
If configuration option is final solution then yes, otherwise it opens
a
new can of worms for backwards (and on-site branching) compatibility.
**
Martin
+0.02
2018-01-02 12:29 GMT+02:00 Korbinian Bachl
<korbinian.bachl@whiskyworld.d
e>:
May I ask why not a simple Config option? When disabled current
behaviour
(default) but when turned on new behaviour? That way it wont break
anything
and may be added to wicket any time?
I just ask because this "not in that version" etc. usually is the
reason
why some Frameworks seems less active/ agile as others. Maybe I miss
the
big picture but I really would hate it if I have to wait for a new
major
version of wicket each time we need to keep up with the developement
of
the
browsers... long time ago there was a discussion what version of
jQuery
should be in wicket and it went on 2, a sane idea at that time, but
now
as
its 2018 I - for example - would instead now only ship JQuery 3.x
default
for wicket as the time has changed.
I wonder how wicket will keep up with that if the cycle is so long
each
time...
Best
KB
PS: I know that you can override the jQuery version as you like, it is
just an example how the "best idea/ way to do it" changes over time
----- Ursprüngliche Mail -----
Von: "Sven Meier" <s...@meiers.net>
An: dev@wicket.apache.org
Gesendet: Dienstag, 2. Januar 2018 10:57:39
Betreff: Re: 8.0.0 blockers
Hi Maxim,
I don't think WICKET-6498 will be part of Wicket 8:
There are still conceptual open questions (who decides what
resources to
defer)
and implementation issues, i.e. does the proposed solution with
addEventListener work in all browsers.
Thanks for testing this.
Sven
Gesendet mit Blue
Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik <
solomax...@gmail.com
schrieb:
I'll try to test WICKET-6498 today/tomorrow
On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
I’m working on restyling the QuickStart to look like the new
examples. Not
a blocker but would be awesome to include. Will work on it 2nd Jan
Martijn
Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bachl <
korbinian.ba...@whiskyworld.de>
May I also mention WICKET-6498?
https://issues.apache.org/jira/browse/WICKET-6498
----- Ursprüngliche Mail -----
Von: "Sven Meier" <s...@meiers.net>
An: dev@wicket.apache.org
Gesendet: Freitag, 29. Dezember 2017 16:22:47
Betreff: Re: 8.0.0 blockers
Not strictly necessary, but I would like to merge WICKET-6503:
https://issues.apache.org/jira/browse/WICKET-6503
Have fun
Sven
Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
Hello All,
Is it time for release?
There are long holidays upcoming here, so I can send more time
on
Wicket
:)))
On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene <
an.delb...@gmail.com>
wrote:
On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
No technical blockers AFAIK, however, we really should do the
marketing
right:
- front page of website should feature 8 prominently
- work with Sally from PR for a press release to let the world
know
we
are
not Dead Yet™
- have a really great announcement to give to the world about
all
the
benefits of Wicket 8
What are the key features that necessitate upgrading to Wicket
8?
Not blocking but really important:
- have a story to answer "Why not just use XXX.js?"
- have a story to answer "Isn't Java Server Side frameworks
dead?"
I (partially) covered these two issues in my presentation.
Maybe it
can be
helpful for further considerations:
http://events.linuxfoundation.org/sites/events/files/slides/
Wicket_The_story_so_far_and_beyond.pdf
- have a story to answer "Isn't Java dead"
Java will never die :-)
Have a call list for when a reporter wants to have contact
about
Wicket 8
and its future (esp. related to questions above)
Other things to consider:
- prepare some articles to publish to dzone, voxxed, etc.?
I'm preparing an article for dzone. You can find it here:
https://www.dropbox.com/s/l9ec2plxyhe4aa2/article8.txt
Any feedback is welcome!
Martijn
On Wed, Nov 29, 2017 at 3:32 AM, Maxim Solodovnik <
solomax...@gmail.com>
wrote:
Hello All,
do we have any blockers for 8.0.0?
--
WBR
Maxim aka solomax
--
Become a Wicket expert, learn from the best:
http://wicketinaction.com
--
Become a Wicket expert, learn from the best:
http://wicketinaction.com
--
WBR
Maxim aka solomax
