[Wikitech-l] MW support for Composer equivalent for JavaScript packages
Hey, I just wanted to check in about the status of enabling JavaScript package management usage in MediaWiki. I am basically talking about an equivalent for JS to what we have with Composer for PHP. Real-world example: The data-values/value-view package[0] is defining jquery.event.special.eachchange.js: ValueView/lib/jquery.event/jquery.event.special.eachchange.js Now, recently I needed the same functionality in one of my extensions, so I just copied it over. [1] I know that this is the worst way one could do this, but as far as I can see we don't have that much of a choice right now. Here are the alternative options I can see: Moving jquery.event.special.eachchange.js out of the data-values/value-view package into its own WMDE/jquery-eachchange package... 1. ... and using it in my extension via composer. + pro: two or more extensions or other packages requiring this package will still result in having only one MW-wide installation.. - con: requires MW specific code which is actually not related to the MW-independent package to feed the resource loader. - con: using Composer to manage pure JavaScript packages! Uuuh, ugly! 2. ... and having a build step in other packages using the package, pulling the WMDE/jquery-eachchange somewhere into the file structure of the packages/extensions using it. + pro: don't need to abuse composer, we can use npm, Bower or any other arbitrary JS package manager here. - con: got to tell resource loader somehow... (didn't think so much about that yet) - con: if more than one extensions or other packages require this package we still end up with the same code twice or more often in one MW installation. 3. Combining 1 and 2: Start with 2, using a JS package manager. Then going to 1, creating a composer package and pulling the WMDE/jquery-eachchange package in via some build script. + pro: The two pros from 1 + 2 + pro: ^^ - con: still got to tell resource loader somehow... - con: Overhead; We now create two packages where the Composer one is just a bridge to the MW-world, still polluting packagist.org. Still kind of ugly and more effort for publishing a package and therefore potentially scaring programmers away from doing so since they've got better things to do than doing work that could be automated. I have not seen Approach 2 and 3 yet. Though I could imagine that the VisualEditor team has used something like that. Approach 1 is the way the data-values/value-view package itself is being handled. And that package should actually be a MW independent pure JS package but right now it contains MW specific code and uses composer for distribution! There is still another option but that had to be properly implemented: 4. Choose one native JS package manager for now and go with it (add support for others later perhaps). Integrate it properly with MW (resource loader to begin with), document how to use it and finally distribute JS code coming from the MW world but useful for other projects in a way where it can actually be used in a non-MW context. This has already been bugging me when working on Wikidata. Now I'd like to reuse some of the code I have written there without spending hours and hours with option 3 because there should be support for option 4 rather sooner or later. So I am wondering; Does anyone have any thoughts, any alternatives perhaps or is there any roadmap on anything like the option 4 that I have shown? Cheers, Daniel [0]: https://packagist.org/packages/data-values/value-view [1]: https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/resources/vendor/jquery.event.special.eachchange.js ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FYI: HTMLForm is now available in OOUI format
Great work! I have noticed that the ooui HTMLForm format is also not supporting a form field's hide-if expressions yet. Cheers, Daniel On 22 July 2015 at 16:06, Florian Schmidt florian.schmidt.wel...@t-online.de wrote: Yay :D Sent from my HTC - Reply message - From: Bartosz Dziewoński matma@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] FYI: HTMLForm is now available in OOUI format Date: Wed, Jul 22, 2015 15:45 It took a while, but most of the issues are ironed out now. OOUI still doesn't support subsections, as that would require some refactoring of gnarly old code. Everything else should work well enough. -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Adding extensions under packagist's mediawiki vendor
Thank you folks! I guess I wasn't logged in when I first tried. It works fine now [0]. Anyhow, I am with Gergo and Jeroen on the issue of code hosting and I chose to use GitHub. I also have lots of extensions on WM's facilities and won't change that in the near future but I am switching to GitHub as I am maintain more and more also non-MW related packages there and I feel like it is less troublesome even though I have also worked on Gerrit for 19 months on a daily basis when working as part of the Wikidata team. Also, some of the biggest MW extensions such as Semantic MediaWiki and Maps seem to be hosted on GitHub already and I can not see how they would lack any support from our community in terms of contributions. Cheers, Daniel [0]: https://packagist.org/packages/mediawiki/user-bitcoin-addresses On 22 July 2015 at 00:57, Bryan Davis bd...@wikimedia.org wrote: On Tue, Jul 21, 2015 at 5:42 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey Bryan, What exactly justifies such an authoritarian need to go though some permission process setup? Exactly what problems are we currently seeing? I'm very sceptical about such an approach. Sure you can say things such as that I'd be nice for other people to have access. The reality is that most people don't care about most extensions and that a lot of them end up being unmaintained and very low quality to begin with. Telling volunteers they should go follow a process they do not want to follow and that they should use a code hosting service they do not want to use has its down sides. This was also not done in the past. You did not need approval to create a certified MediaWiki extension or something like that. As of https://github.com/composer/packagist/issues/163#issuecomment-99673878 Packagist itself has created this restriction of vendor namespaces actually indicating some level of ownership. A vendor is a supplier of a good or service. Publishing something as mediawiki/* is explicitly claiming affiliation with the MediaWiki open source project. As such it seems not unreasonable to ensue that projects claiming to be supplied by the MediaWiki community actually are indeed serviceable by that community. Note that there is no form of restriction for publishing a package that provides a MediaWiki extension or other related functionality under another namespace. I would certainly welcome an RfC discussion of the current policy and a potential replacement. From my point of view, use of the MediaWiki brand implies endorsement by the MediaWiki community and thus should only be easily available to projects that are able to be contributed to and managed by that community. If for example a serious security flaw was found in a mediawiki/foo package on Packagist the community should be empowered to fix it. Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID USA irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Adding extensions under packagist's mediawiki vendor
Hi, I'd like to add my extension https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses as mediawiki/user-bitcoin-addresses in packagist. When trying to do so, packagist states I should ask someone with the proper rights to maintain the mediawiki vendor. I have read up on https://www.mediawiki.org/wiki/Manual:Developing_libraries#Packagist_guidelines And I wrote two of the guys listed to have access to the mediawiki vendor account but I am not sure I am getting a reply so I thought I'd also try it through this channel. Any advice how I'd get my GitHub repo on packagist under the mediawiki vendor would be highly appreciated. Cheers, Daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Page title length
This is not an exact answer to your question, but rather a simple and
powerful alternative.
If you are thinking about using Semantic-MediaWiki (which would be
very applicable for a Wiki about resources), you should have a look
at:
http://www.mediawiki.org/wiki/Extension:SemanticTitle
The SemanticTitle extension seems to be currently unmaintained but
just yesterday there has been a talk at SMW-Con here in Berlin which
revealed plans by MITRE to soon commit their recent changes on the
extension and perhaps even maintain it in the future.
More information about the talk:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2013/Revolutionizing_page_naming_with_semantic_properties
The slides of the talk are already available on that page, a video
recording should follow soon.
Cheers,
Daniel Werner
2013/10/24 Élie Roux elie.r...@telecom-bretagne.eu:
Dear MediaWiki developers,
I'm responsible for the development of a new Wiki that will contain many
Tibetan resources. Traditionnaly, Tibetan titles of books or even parts of
books are extremely long, as you can see for instance here :
http://www.tbrc.org/#!rid=W23922, and sometimes too long for Mediawiki, for
instance the title of
http://www.tbrc.org/?locale=bo#library_work_ViewByOutline-O01DG1049094951|W23922
, which is
ཤངས་པ་བཀའ་བརྒྱུད་ཀྱི་གཞུང་བཀའ་ཕྱི་མ་རྣམས་ཕྱོགས་གཅིག་ཏུ་བསྒྲིལ་བའི་ཕྱག་ལེན་བདེ་ཆེན་སྙེ་མའི་ཆུན་པོ་
. This title is around 90 Tibetan characters, but each caracter being 3
bytes, it exceeds the limit for title length of 256 bytes that MediaWiki
has.
So I have two questions:
1. If I change this limit to 1023 in the structure of the database
('page_title' field of the 'page' base), will other things (such as search
engine) break? Is there a way to change it more cleanly?
2. Could I propose you to make this limit 1023 instead of 255 (or to make it
configurable easily)? This would allow at least 256 characters (even for
asian languages) instead of 256 bytes, which seems more consistant with the
fact that MediaWiki is well internationalized.
Thank you in advance,
--
Elie
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update to jQuery 1.9 and jQuery UI 1.9
Still wondering about the same question every week. Are there any plans/schedule for updating to jQuery/jQuery UI 1.9 at this point? Would be neat to have the new jQuery.ui.Widget related features of 1.9 available. Cheers, Daniel 2012/12/6 Jan Luca j...@jans-seite.de Hi, is there already a schedule to update jQuery and jQuery UI to 1.9 or are there problems at moment? I want to use the new tooltip widget of jQuery UI 1.9 [1]. Best regards, Jan [1] http://jqueryui.com/tooltip/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extending Scribunto with new Lua functions
2013/2/4 Brad Jorsch bjor...@wikimedia.org: You'd add your library object in Lua as a child of the mw object. Sounds like same little mistake we are already dealing with in JavaScript, see: http://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/JavaScript#Place_for_Extensions_Objects_in_JavaScript_20654 Perhaps not too late to get this right in Scribunto from the beginning. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Message system based HTML snippets
There is a first implementation of this in the Wikibase extension now:
https://gerrit.wikimedia.org/r/#/c/28680/
This implements the html snippet functionality in PHP. The JS side will be next.
2012/10/18 Daniel Werner daniel.wer...@wikimedia.de:
Right now we are about to implement some kind of basic template Engine
to share HTML on the server side as well as on the client side in
JavaScript. Basically this will be a bunch of HTML snippets which we
will put into a resource loader module and send to the client. The
snippets will need some kind of placeholder which can then be replaced
with different content. The replacement would be done by some basic
parser which had to be implemented in PHP as well as JS.
One thought was to simply use the MW message system for this. The
templates would of course get their own store, but the message parser
could perhaps be reused. $1 etc. could be used as placeholders and
even nice-to-haves such as PLURAL or {{int:}} would work out of the
box.
From a first look, it could be as easy as overwriting
Message::fetchMessage in as subclass.
Off course it had to be taken care of the JavaScript side as well.
Doesn't seem like mw.Message would be a problem.
Any thoughts on this or does anyone know about some similar
implementation in any extensions?
Cheers,
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Message system based HTML snippets
Right now we are about to implement some kind of basic template Engine
to share HTML on the server side as well as on the client side in
JavaScript. Basically this will be a bunch of HTML snippets which we
will put into a resource loader module and send to the client. The
snippets will need some kind of placeholder which can then be replaced
with different content. The replacement would be done by some basic
parser which had to be implemented in PHP as well as JS.
One thought was to simply use the MW message system for this. The
templates would of course get their own store, but the message parser
could perhaps be reused. $1 etc. could be used as placeholders and
even nice-to-haves such as PLURAL or {{int:}} would work out of the
box.
From a first look, it could be as easy as overwriting
Message::fetchMessage in as subclass.
Off course it had to be taken care of the JavaScript side as well.
Doesn't seem like mw.Message would be a problem.
Any thoughts on this or does anyone know about some similar
implementation in any extensions?
Cheers,
Daniel
--
Daniel Werner
Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTMLMultiSelectField as select multiple=multiple/
Alright, you convinced me that a scrollable(!) list of check boxes (using overflow scroll) might be better than a multi select. That is if you have at least CSS enabled. Without CSS I would definitely go for a multi-select because a list of 300 checkboxes still sucks more in my opinion. I guess I could change my change set to add those css styles rather than using a multi-select, or even add some css per default to avoid utterly long lists of checkboxes. On the other hand, this had been on the list and in review for months now and there are people who would find a multiselect useful apparently. It seems close to impossible to make it right for everybody. It doesn't really seem productive nor motivating to question small changes like this in all details after non trivial amount of work has gone into it by different parties (discussion, several patch-sets, reviews). For now I have abandoned this since I don't even need it anymore in STTL. So may someone else try to improve upon it or not. Cheers, Daniel 2012/10/1 Krinkle krinklem...@gmail.com Nobody (afaik) is saying that jQuery chosen isn't better than a bunch of checkboxes. The point is that select multiple (without javascript enhancement) is horrible and (imho) unacceptable. And no, it is not because we found situations in which it is not a good idea. It is because it is never a good idea, never. The solution I'd propose (and Daniel also mentioned this various times here and elsewhere) to output checkboxes as fallback and an interface like jQuery Chosen as enhancement. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTMLMultiSelectField as select multiple=multiple/
On Sep 29, 2012, at 4:51 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote: Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it. Sure, as long as there is JS available we should turn the multi-select into something nicer. But the original idea behind this was that a multi select would still be more user friendly than an endless list of check-boxes when having around 300 choices (e.g. for languages). Take jQuery chosen for example (thanks for the link Yury), it takes a multi-select as source and turns it into some very nice piece of UI. It doesn't matter whether you originally have a bunch of check-boxes or a multi-select from a JS perspective. Anyhow, I would still appreciate if someone would merge the thing, it's sitting around for too long already and it seems that it got stuck because of some very minor issue once again: https://gerrit.wikimedia.org/r/#/c/8924/ Thanks! -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should we make parser test executions via phpunit.php behave like running them with parserTests.php ?
I remember that some more methods could be shared if the parameter order of parserTests.php was changed Not sure whether params order has to change but yest, more code there could be shared. No idea why the localsettings are not shared for example. That was done for creating the articles once, outside of the test loop. Originally they were also created in place, but inserting all articles for each test was really slow. Ok, here is why I want articles to be created in-between tests, within the test loop: http://pastebin.com/g694dG6L Also, I want to change the local settings before creating certain articles, to create them with lower-case characters for some tests. I would suggest taking the lost in performance into account for that, it gives more flexibility for the tests. Or do are there any other ideas? Also see my patch-set https://gerrit.wikimedia.org/r/#/c/20534/ which is blocked by this problem, here I wanted to introduce the !!config sections into !!article. !!config is also something new I have introduced to parser tests in case you haven't seen it yet. Cheers, Daniel 2012/9/1 Platonides platoni...@gmail.com On 31/08/12 12:01, Daniel Werner wrote: Hi everyone, Started poking on parser tests lately and found myself riddled after a while. It seems like when running parser test files with phpunit.php they follow different rules as when running them with parserTests.php. If I observed this correctly, phpunit.php collects all articles to be created with !!article, creates them, and then it runs tests. With parserTests.php on the other hand everything is executed in the order it is defined. In some tests it can be important whether a article already exists or not. That was done for creating the articles once, outside of the test loop. Originally they were also created in place, but inserting all articles for each test was really slow. If a test relies on some articles existing, those should be defined before it. If it's not documented, it should be. With that rule in place, the difference on creating at the start or on demand doesn't matter. (...) I would very much appreciate if anyone could explain to me why there are both of these files and why we maintain (more or less) a whole bunch of redundant code for those tests. Cheers, Daniel Someone did a crappy work when creating the phpunit parser tests, duplicating a lot of code and sharing none between them. It was later improved by several people, as years passed, I did myself several fixes to the phpunit code. I think it is easy to compare them with a visual diff tool. I remember that some more methods could be shared if the parameter order of parserTests.php was changed. Best regards ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Should we make parser test executions via phpunit.php behave like running them with parserTests.php ?
Hi everyone, Started poking on parser tests lately and found myself riddled after a while. It seems like when running parser test files with phpunit.php they follow different rules as when running them with parserTests.php. If I observed this correctly, phpunit.php collects all articles to be created with !!article, creates them, and then it runs tests. With parserTests.php on the other hand everything is executed in the order it is defined. In some tests it can be important whether a article already exists or not. There might be other behavioral differences here as well. The whole thing seems incredibly odd to me since there is also some redundant code and the initial globals set up in ParserTest::setupGlobals() are slightly different from globals set up in NewParserTest::setupGlobals(). If there is no good reason against this, both classes, ParserTest and NewParserTest should be reduced to one, or at least one base class/interface. The goal should be that when running phpunit.php parser tests behave exactly like running parserTests.php Already created a bug report for this as well, it just didn't get any attention so far, so I try it here: https://bugzilla.wikimedia.org/show_bug.cgi?id=39473 I would very much appreciate if anyone could explain to me why there are both of these files and why we maintain (more or less) a whole bunch of redundant code for those tests. Cheers, Daniel -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
In that case, perhaps we should just say that all of the options are fine:
$( 'div' )
$( 'div/' )
$( 'div/div' )
but emphasize not to use attributes in the tag creation.
+1
All three will return the same, and this is not HTML, it's JavaScript. It
really is just a matter of personal flavor in coding style, nothing else.
By the way, you can also use
$( 'div/', { 'class': 'foo', 'title': 'myTitle', ... } );
for adding attributes right away. Should be faster, more readable and less
error-prone than using tags directly in the div's definition string.
Cheers,
Daniel W
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] JavaScript mv* framework for MediaWiki?
Hi everyone, some of us at Wikidata[1] are currently thinking about the best approach to improve the connection between our backend (web API) and our JavaScript front-end. What we basically want is to make our data model available in the front-end in a broader span. This will allow us to go for more decoupled components (model/viewer) but hopefully it will also allow gadget developers to fetch, handle, present and store data with much less effort. Since there might be some existing JavaScript frameworks well suited for this already, it might be worth considering them for the job. Backbone, Spine, Knockout, Serenade or Ember are just a few names out of many. Has there been any discussion touching this area so far or is this even used in some wip MediaWiki project? I could for example imagine the Visual Editor requiring some kind of approach going this direction... anything? I think this is similar to the decision to ship MW together with jQuery instead of a similar library. So I guess if we would choose any of these frameworks, it should be a lightweight one, allowing for great flexibility to reuse this in MW extensions and core, not having to introduce another one later which would just mean more confusion for new developers and additional load between clients and servers. In Wikidata, the first thing we would use any of those frameworks would be to provide Wikidata Items[2] (or other entities) by fetching them via the web-API, allowing modification to those fetched objects and then storing all changes made back to the server via the web-API. Also see my draft[3] with the idea of introducing a JS prototype for Entity/Item as well as FetchedEntity/Item which could probably be implemented using one of those frameworks. This discussion should be both, talking about experience with such frameworks as well as dealing with the question whether it would make sense to introduce something of this art into core in the near future or not. Any thoughts on this would be highly appreciated! Cheers, Daniel W. -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Request for comment -- Extension management
Part of this should be a base class for extensions to use, e.g. WikiMediaExtension. Should be nice to save some code needed in all extensions and perhaps we could deprecate some globals related to extensions registration. Also, this will require some updates for the extensions development manuals on mw org. This could probably even be done and discussed in parallel of the configuration database development. 2012/7/30 Daniel Renfro bluecu...@gmail.com: Well, I'm willing to work on an extension manager whenever it is ready to be started. Feel free to edit the RFC page, I'm trying to make it fairly comprehensive. -Daniel On Sunday, July 29, 2012 at 10:36 AM, Chad wrote: On Sat, Jul 28, 2012 at 9:29 PM, Daniel Friesen li...@nadir-seen-fire.com (mailto:li...@nadir-seen-fire.com) wrote: Speaking of Chad. He's been dying to work on his project trying to create a configuration database for MediaWiki. He's been busy with Gerrit stuff but hoping to work on configuration after that's done. I think that extension management is the second step. We can't have a good system for installing extensions in a UI when we don't even have a good system for configuring MediaWiki in a UI. Yes. Let's please please please not try to tackle this until config mgmt is in core. Extension pages can ONLY exist (excluding subpages) if an extension has been defined in the database, a path to the repo given, and author(s) defined I see no reason to lock in an Extension: page = part of the repository setup like this. We can provide parser functions and whatnot to display extension information on Extension: pages on MW.org (http://MW.org). And we can use some method to use information on the extension base itself to define some information for extensions, etc... but Extension pages and extension management will be two separate things. This was a silly idea I had when writing this up originally. The main goal was to prevent extensions pasted into wiki pages. Unless you just mean that new versions of MediaWiki should keep working with old require_once based extensions until they migrate to the extension installer setup. This. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP namespacing and traits
2012/7/5 Daniel Friesen li...@nadir-seen-fire.com: On Thu, 05 Jul 2012 01:01:13 -0700, Antoine Musso hashar+...@free.fr wrote: Hello, PHP 5.3.0, released in June 2009, introduced namespacing, a feature we have never used yet since we were still supporting 5.2. Jeroen submitted https://gerrit.wikimedia.org/r/14181 which use namespaces. Since that is, to my knowledge, the first patch that introduce namespace, I am opening this thread so we discuss about namespace introduction in MediaWiki. PHP doc http://php.net/manual/en/language.namespaces.php Thoughts? I maintain that use of namespaces should be on a case-by-case basis. Only used if there's a significant advantage to using namespaces for some code. eg: A component with a huge pile of small classes for pieces of the component. In this case, I don't see a good reason to use a generic MW namespace. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l By all means, GO for it at least in extensions. Namespaces are awesome there since they can spare you a lot of prefixing extension classes. Have not made my mind up about core though, there might be valid reasons why not to use them there. -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension Skeleton Program
Sounds nice, but on the long run, why not including a PHP class for extensions into core. This would already make quite some code you need for new extensions obsolete. I'd like to see a base class for all extensions which offer simple information such as the extensions name, version, file path, etc. 2012/7/2 Andrew Garrett agarr...@wikimedia.org: Ooh, I like this. On Thu, Jun 28, 2012 at 7:37 AM, Ori Livneh o...@wikimedia.org wrote: On Monday, June 25, 2012 at 9:06 AM, Derric Atzrott wrote: Would anyone be interested in a program that generates Skeletons for new extensions? I've noticed that when I make extensions I generally go through the exact same process (with minor variations) each time. [ snip ] I've been working on something similar, so I decided to throw it up on GitHub, in case it's useful. It's a skeleton extension for JavaScript-centric MediaWiki extensions. https://github.com/atdt/skeljs Out of the box, you get: * QUnit test scaffold * ResourceLoader integration * MediaWiki-compatible JSHint config * Command-line build tool (grunt) for linting and running Qunit tests using phantomjs I've only recently started developing on MediaWiki so this definitely needs to be reviewed. (*cough* Krinkle / Roan / Trevor?) Derric ( others): feel free to use this in any way you want. I'll migrate this to Gerrit when I get the chance. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Andrew Garrett Wikimedia Foundation agarr...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making language selection sticky
Just stumbled over the GetLocalURL::Internal (http://www.mediawiki.org/wiki/Manual:Hooks/GetLocalURL::Internal) hook which was introduced in MW 1.19. This works pretty fine, just doesn't work for page content but that can be done with the linker. It works for pretty much everything else though, e.g. sites nav and tabs on top of the page. I am not sure though whether this is breaking anything. Putting it in there is pretty deep, so whenever an url is requested from any title object, the uselang parameter is attached to it. Seems to work fine so far. Cheers Daniel W. 2012/6/27 Platonides platoni...@gmail.com: On 27/06/12 11:43, Denny Vrandečić wrote: 2012/6/26 Platonides platoni...@gmail.com: On 26/06/12 18:48, Denny Vrandečić wrote: We tried to change the linker in order to add the uselang parameter every time -- but it only works in the content, not in the sidebar and actionlinks. We could put the language into a cookie, as the ULS currently does, but this means that the squid caches won't work, afaik. You are going to fragment the caches whether you use a parameter or a cookie. IMHO the cookie option is a cleaner one (I think that would also allow to make a single purge). We thought about using the uselang only if it is not the main used language (i.e., usually en), which means the caches would kick in 40% of the time at least. You mean serving other language directly from the apaches? Could be done. But would they support a 50% of the squid load? The cookie thing wouldn't have such a convenient default AFAIK, but I might be really easily wrong here. I think it could be done both ways. If the page is cacheable, the squid/varnish would store the page with the cookie value, and then serve it only for those request with the same cookie value. We could take the output just before it is send to the browser and regex-substitute all the links in order to add the uselang parameter every... OK, half joking. Only half. Some wikis have a javascript which does exactly that, adding a userlang parameter the moment you click a link. Much better than a string regex :) But only working if JavaScript is available. Sure, that's the limitation :) You would still cover almost everyone but jidanni ;) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Registering JavaScript vars for only a certain resource loader module in php
I was wondering whether it is possible somehow to register a javascript var for a certain resource loader module in php? There is the OuputPage::addJsConfigVars function but I didn't find anything to only load a var only conditionally when a module is loaded. Right now I am registering a variable in the ResourceLoaderGetConfigVars hook, but actually, I only want to have it included when the 'wikibase' module is loaded since it is rather big and shouldn't be loaded when not necessary. -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Maps extension graphical editor.
Looks good and helpful to me. One thing not working yet is the marker icons switching color when assigned to a group. You could take the markers from the maps extension directly for that. By the way, the url is http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmlwithout the - in the end. 2012/5/31 Ole Palnatoke Andersen palnat...@gmail.com URL correction: http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.html- there was no space between this and and. On Thu, May 31, 2012 at 8:49 AM, Kim Eik k...@heldig.org wrote: Hi guys, i have created a simple map editor which works with the Maps extension, i'm looking for some feedback on your impression of it. please take a look @ http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw2.htmland let me know what you think. and also, please note it's a work in progress. My idea is to implement this as a special page in the Maps extension so that people can easily create and edit maps. Cheers Kim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- http://palnatoke.org * @palnatoke * +4522934588 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTMLMultiSelectField as select multiple=multiple/
Message: 8 Date: Wed, 23 May 2012 21:49:57 +0200 From: Platonides platoni...@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] HTMLMultiSelectField as select multiple=multiple/ Message-ID: jpjf1s$b23$1...@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 On 23/05/12 19:16, Daniel Werner wrote: Right now I am implementing a new option (as part of https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to use a select multiple=multiple/ html element with options. Right now MediaWiki always generates a list of selectboxes instead of that when using the HTMLMultiSelectField class. We are talking about 280+ selectable items here, so for now we came to the conclusion that a real multi select/ would be nicer and less space consuming for now I have already managed to implement this multiple select, modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which can be set to false to disable the known behavior and use a select element instead. This would mainly be for the JavaScript-less ui. If javascript were enabled, we could still do something nicer, for example with something like jQuery chosen plugin here. My question would just be, how I should implement these changes preferably. Is it ok with the new option for HTMLMultiSelectField or should this be a new class inheriting from HTMLMultiSelectField? I think HTMLMultiSelectField sounds more like describing what I just implemented rather than a bunch of select boxes, but of course renaming the existing one could break extensions (even though both are fully compatible and interchangeable). So one option would be simply naming the new one HTMLMultiSelectField2 if we don't want to stick with an additional option here. No. You shouldn't need to know that HTMLMultiSelectField2 is a MultiSelect but HTMLMultiSelectField uses checkboxes. Your useCheckboxes looks good. I recommend you to make it a tri-state value, so you could force checkboxes, select or let it decide (eg. checkboxes for 100 elements, select for more) Alright, just submitted this for review to gerrit: https://gerrit.wikimedia.org/r/#/c/8924/ I implemented it as tri-state now. By default 'usecheckboxes' will be true, not set to a number. This could be changed (would make sense imo) but for now I didn't want to do this since it could for example affect the default search namespace user preference in wikis with many search namespaces. I think the plain multiple select HTML element is not that nice because it is not very obvious that you can do multiple selects by holding the control key. There should be some JavaScript ui element replacing this for users having JS enabled I think before using this as default for huge multiselect options. I think if all of that were implemented, 15 or 20 would be a good default value for the option. Cheers Daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] HTMLMultiSelectField as select multiple=multiple/
Right now I am implementing a new option (as part of https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to use a select multiple=multiple/ html element with options. Right now MediaWiki always generates a list of selectboxes instead of that when using the HTMLMultiSelectField class. We are talking about 280+ selectable items here, so for now we came to the conclusion that a real multi select/ would be nicer and less space consuming for now I have already managed to implement this multiple select, modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which can be set to false to disable the known behavior and use a select element instead. This would mainly be for the JavaScript-less ui. If javascript were enabled, we could still do something nicer, for example with something like jQuery chosen plugin here. My question would just be, how I should implement these changes preferably. Is it ok with the new option for HTMLMultiSelectField or should this be a new class inheriting from HTMLMultiSelectField? I think HTMLMultiSelectField sounds more like describing what I just implemented rather than a bunch of select boxes, but of course renaming the existing one could break extensions (even though both are fully compatible and interchangeable). So one option would be simply naming the new one HTMLMultiSelectField2 if we don't want to stick with an additional option here. Cheers Daniel -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] #parser parser function - does this make any sense?
I am thinking about creating a very simple parser function #parse doing
nothing but returning parameter 1 with an 'noparse' = false option.
Is there anything like this (or what could be abused for this) already
or is there any reason why this might be a bad idea?
The reason I want to have something like this is, I want to create a
template (for template and parser function black-box tests) accepting
something like {{((}}#somefunction:a{{!}}b{{!}}c{{))}} as parameter
value, showing {{#somefunction|a|b|c}} as output and at the same time
calling {{#parse: {{((}}#somefunction:a{{!}}b{{!}}c{{))}} }} so that
besides the definition also the result can be shown by the template output.
regards,
Daniel
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Maps extension image layer enhancements
Hi,
Actually, I sent a mail to the maps mailing list already but there was
no feedback at all so I am taking Jeroens advice and try it again here,
there might be some users using maps and waiting for the image maps
feature. I already included some of the features suggested in my last
mail to map...@lists.wikimedia.org a little different though.
Recently I have been fixing the Maps extension openlayers image feature
to use images as maps again (the feature was broken around Maps 1.0).
Besides fixing the feature for the next version of maps, I have
implemented the following features already:
* Additional parameters on layer pages (unit, maxScale, minScale) to
better control how the map is being displayed.
* Markers can have a group, each group is represented as one overlay
layer and has its own marker colour (for default markers).
* the display_... functions/tags using a layer: page store this in the
database, layer-pages show which pages are using the layer and pages
using a layer will be purged when the layer changes.
* Database table for layers which should increase performance and allows
to define several layers in one page to group them. Using the layer page
name will include all of these group members into the base map-selection
of a map. Also, a layer name= type=...properties.../layer tag is
used to define layers now. Via 'name' the layer can have a name so a
specific group member layer can be used instead of the whole group of
layers defined on the same layer-page.
now I am writing because I am planing on implementing some more features
which I need some opinion on:
1. I have implemented first attempts of allowing overlay maps. The
overlay feature introduces the attribute 'overlays' for 'display_map'
and 'display_point' like:
display_map service=openlayers layers=Moon Map overlays=Moon
Station, Moon City0,0/display_map
where 'Moon Station' and 'Moon City' could be smaller maps located on
'Moon Map', simply images with more detail where you can zoom in from a
overall view of moon into a detail view of the base and the city. The
cool thing about this is, that overlay maps also could be displayed as
baselayers if you use them with the 'layers' parameter instead (since
they must have a layer: page anyway)
This works, but it doesn't make much sense without coordinates for the
overlays. So I am thinking about a appropriate syntax but can't come up
with anything nice:
display_map service=openlayers layers=Moon Map overlays=Moon
Station|20;40, Moon City|100;400,0/display_map
for example wouldn't be very consistent syntax compared to the other map
syntax and I don't even want to think about #display_points which has
some weird syntax compared to display_points
How about:
display_map service=openlayers layers=Moon Map overlays=Moon
Station|Station, Moon City|City addresses=Station (20,40), City
(100,40)0,0/display_map
So we would first declare some named addresses and assign them to
coordinates, from then on we can use the names for image layers just
like in mapping services like bing or google maps where you can just
write 'New York' instead of the actual geographical coordinates. And not
using the () within 'overlays' has the advantage that layer sites still
can contain '(' and ')' within the site name. It also allows to use the
addresses for markers like:
display_points service=openlayers layers=Moon Map overlays=Moon
Station|Station, Moon City|City addresses=Station (20,40), City (100,40)
Station | Moon Station | This is the moon station | station.png | Group 1
/display_map
So instead of using coordinates we can use names as coordinates for
markers within image layers as well!
This goes even one step further with the following...
2. ...allowing to define addresses within the layer page. This could be
a parameter 'addresses' which contains coordinates and names of
addresses which can be used for overlays and markers for 'display_point'
and for overlays using 'display_map'.
This could look like:
layer type=image
source = moon.jpg
...
addresses = station (20,40), city (100,40),
/layer
addresses would be case-insensitive and would even make the use of the
'addresses' parameter within the display functions obsolete when using
overlays but the main advantage would of course be that markers can be
added very fast and without searching for coordinates first since all
important coordinates are described already.
'addresses' parameter of display functions will overwrite if one name is
given there and on a layer page.
3. its difficult with units. Layers can have different units like
degree, km, miles... I didn't look into how it works if markers with
units are defined in display_marker if there are layers with different
units. Perhaps we should allow coordinates with units like 20km,200m
to make it clear. This could also be included in layer pages so we can
say left-extend=20km and stuff like that instead of having a unit
attribute.
There
