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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
