Dmitriy Sintsov wrote:
If I understand correctly, current js2-work branch
will be a base for
1.17?
No, not really.
Is there any way to make old MonoBook derived skins to
be
compatible with js2 code?
The js2-work branch doesn't delete anything, it's just a ton of new code.
I have lots of them. Actually, since long time
skin implementation code was fast but has very non-modular structure
with no clear data and visualization separation, no structurized methods
for sidebar, tooltips and so on. Templating was done in the far past
(CBT) but that probably was considered not efficient enough for heavy
load sites. For the efficiency, it should be possible to write a skin
generator, where the nice templatable format of skin will be converted
to efficient but spaghetti-like PHP code.
The CBT project included a compiler to PHP. The entire skin was
converted to a single expression which, when evaluated, gave you the
HTML output. Lots of concatenation and ternary operators were
involved. It had a dependency tracker, which allowed you to replace
constant parts of the template with literal strings. For instance, you
could have it generate and cache a separate PHP file for each user.
The issue with it was that despite all that work and added complexity,
the speed improvement was not very impressive.
Also, there was no clear win in any other way either. The skin was
just as hard to read, and no easier to customise. Major releases would
still have broken most out-of-tree skins. I came out of the project
thinking that I had found some nice solutions, but to the wrong problems.
I wonder how should I prepare my monobook-derived
skins to make them easier to upgrade someday.
I think that as long as you're thinking in terms of a skin as being an
HTML document with some variable interpolation, then you're going to
lose this battle. The most robust, version-independent skin changes
have proven to be code-based, such as the hook functions or
subclassing. The hooks that work best are the ones that are as
abstract as possible, distantly related to the HTML.
-- Tim Starling