[
https://issues.apache.org/jira/browse/JSPWIKI-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1312:
-----------------------------------
Description:
This is the umbrella of JSPWIKI-811 (migrate from Mootools to jQuery, opened in
2014) and JSPWIKI-1098 (replace the icon fonts by SVG icons), which are both
open. JSPWIKI-811 already has a discussion: jQuery was favoured, the work was
judged to be bigger than a weekend, and a way to let both libraries live
together with jQuery.noConflict was proposed, so that plugins can use jQuery
without migrating the core. This ticket asks to decide the target first, as
native JavaScript may be enough, and to plan the work in pieces.
What there is today, measured in jspwiki-war/src/main/scripts without the
libraries (the lib folder) and the sources of the WYSIWYG editor
(wiki-wysiwyg/Source): 72 JavaScript files with 17,305 lines, 50 of them using
$(, new Class or addEvent. In them $( appears 190 times, $( 29 times, new Class
32 times and addEvent 102 times. The calls to set, setStyle, setStyles,
addClass, removeClass and toggleClass are 242, those to getElement,
getElements, getParent, getParents, getNext, getPrevious, getFirst, getLast,
getChildren and getSiblings 145, new Element 76, each 80, new Request 9, store
and retrieve 9, Fx, morph and tween 7, and Cookie 8. The numbers come from a
text search, so they are approximate. The folder moo-extend holds the
extensions of Mootools classes. mootools-core and mootools-more 1.6.0 are 7,228
lines, and wro4j bundles them for the Haddock style
(config/wro/wro-haddock.xml). The WYSIWYG editor is based on MooEditable, which
is built on Mootools too.
The icons are not from a third-party library but from an own font, FontJspwiki
(woff and ttf files), repeated in the default and reader templates and in the
Haddock style.
Not looked at yet: the 210 template, the Markdown editor, and how many
third-party plugins depend on Mootools.
Proposal: first decide the target (native JavaScript, or a maintained library
such as jQuery) and the browsers to support. Then migrate piece by piece, one
component at a time, with a thin compatibility layer while both exist, and
remove Mootools when nothing uses it. The icons can go separately: one SVG for
each glyph of FontJspwiki, used from the CSS of the three templates.
The user interface has no automated tests, so each step has to be checked by
hand in a browser; some tests for the pieces that are migrated would help. This
ticket is a plan to discuss, probably on
[[email protected]|mailto:[email protected]] first; there is no
implementation.
was:
This is the umbrella of JSPWIKI-811 (migrate from Mootools to jQuery, opened in
2014) and JSPWIKI-1098 (replace the icon fonts by SVG icons), which are both
open. JSPWIKI-811 already has a discussion: jQuery was favoured, the work was
judged to be bigger than a weekend, and a way to let both libraries live
together with jQuery.noConflict was proposed, so that plugins can use jQuery
without migrating the core. This ticket asks to decide the target first, as
native JavaScript may be enough, and to plan the work in pieces.
What there is today, measured in jspwiki-war/src/main/scripts without the
libraries and the third-party editors: 74 JavaScript files with about 17,500
lines, 52 of them using $(), new Class or addEvent. In them $() appears 196
times, $$() 34 times, new Class 53 times and addEvent 151 times. The helpers to
handle the DOM (set, setStyle, addClass, removeClass, toggleClass) are called
about 295 times, getElement(s), getParent and similar 118 times, new Element 86
times, each 91 times, new Request 18 times, store and retrieve 13 times, the
effects (Fx, morph, tween) 7 times and Cookie 4 times. Six extensions of
Mootools classes are in moo-extend. mootools-core and mootools-more 1.6.0 are
about 7,200 lines, and wro4j bundles them for the Haddock style
(wro-haddock.xml). The WYSIWYG editor is based on MooEditable, which is built
on Mootools too.
The icons are not from a third-party library but from an own font, FontJspwiki
(woff and ttf files), repeated in the default and reader templates and in the
Haddock style.
Not looked at yet: the 210 template, the Markdown editor, and how many
third-party plugins depend on Mootools.
Proposal: first decide the target (native JavaScript, or a maintained library
such as jQuery) and the browsers to support. Then migrate piece by piece, one
component at a time, with a thin compatibility layer while both exist, and
remove Mootools when nothing uses it. The icons can go separately: one SVG for
each glyph of FontJspwiki, used from the CSS of the three templates.
The user interface has no automated tests, so each step has to be checked by
hand in a browser; some tests for the pieces that are migrated would help. This
ticket is a plan to discuss, probably on
[[email protected]|mailto:[email protected]] first; there is no
implementation.
> Replace Mootools with native JavaScript or a maintained library, and the icon
> font with SVG icons
> -------------------------------------------------------------------------------------------------
>
> Key: JSPWIKI-1312
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1312
> Project: JSPWiki
> Issue Type: Improvement
> Reporter: Arturo Bernal
> Priority: Major
>
> This is the umbrella of JSPWIKI-811 (migrate from Mootools to jQuery, opened
> in 2014) and JSPWIKI-1098 (replace the icon fonts by SVG icons), which are
> both open. JSPWIKI-811 already has a discussion: jQuery was favoured, the
> work was judged to be bigger than a weekend, and a way to let both libraries
> live together with jQuery.noConflict was proposed, so that plugins can use
> jQuery without migrating the core. This ticket asks to decide the target
> first, as native JavaScript may be enough, and to plan the work in pieces.
>
> What there is today, measured in jspwiki-war/src/main/scripts without the
> libraries (the lib folder) and the sources of the WYSIWYG editor
> (wiki-wysiwyg/Source): 72 JavaScript files with 17,305 lines, 50 of them
> using $(, new Class or addEvent. In them $( appears 190 times, $( 29 times,
> new Class 32 times and addEvent 102 times. The calls to set, setStyle,
> setStyles, addClass, removeClass and toggleClass are 242, those to
> getElement, getElements, getParent, getParents, getNext, getPrevious,
> getFirst, getLast, getChildren and getSiblings 145, new Element 76, each 80,
> new Request 9, store and retrieve 9, Fx, morph and tween 7, and Cookie 8. The
> numbers come from a text search, so they are approximate. The folder
> moo-extend holds the extensions of Mootools classes. mootools-core and
> mootools-more 1.6.0 are 7,228 lines, and wro4j bundles them for the Haddock
> style (config/wro/wro-haddock.xml). The WYSIWYG editor is based on
> MooEditable, which is built on Mootools too.
>
> The icons are not from a third-party library but from an own font,
> FontJspwiki (woff and ttf files), repeated in the default and reader
> templates and in the Haddock style.
>
> Not looked at yet: the 210 template, the Markdown editor, and how many
> third-party plugins depend on Mootools.
>
> Proposal: first decide the target (native JavaScript, or a maintained library
> such as jQuery) and the browsers to support. Then migrate piece by piece, one
> component at a time, with a thin compatibility layer while both exist, and
> remove Mootools when nothing uses it. The icons can go separately: one SVG
> for each glyph of FontJspwiki, used from the CSS of the three templates.
>
> The user interface has no automated tests, so each step has to be checked by
> hand in a browser; some tests for the pieces that are migrated would help.
> This ticket is a plan to discuss, probably on
> [[email protected]|mailto:[email protected]] first; there is no
> implementation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
