Re: [Wikitech-l] New preferences system

2009-04-25 Thread Aryeh Gregor
On Fri, Apr 24, 2009 at 6:50 PM, Brian brian.min...@colorado.edu wrote:
 Whatever happened to object-oriented programming and abstraction? Why can't
 you define and provide a consistent API?

Object-oriented programming and abstraction do not magically avoid the
problem of requirements and functionality changing over time.  It's
possible to provide a very stable API, but it takes a lot of work.
It's necessary for, say, an operating system (and even they often mess
up), but it's just not worth it in most other cases.  Firefox
extensions also sometimes break on upgrade, for instance.  The same is
true for extension mechanisms in the large majority of software.

You have to weigh the costs against the benefits in all cases.  Since
no actual significant costs have yet been presented here, this whole
line of discussion seems like a tempest in a teapot.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Jacopo Corbetta
On Fri, Apr 24, 2009 at 05:59, Andrew Garrett agarr...@wikimedia.org wrote:
 I'd like to look towards trimming some of the existing preferences
 that are no longer relevant, and adding new preferences as common
 sense dictates.

Can I suggest adding a preferred editor preference?
Ideally, it should be a dropdown box (given the variety of existing
visual editors 
http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions/Nomination#Editing,
an admin might wish to install more than one), but a simple disable
the visual editor checkbox is probably enough for most setups (and
simpler to maintain).

Thanks, bye
--
Jacopo Corbetta
j.corbe...@sssup.it
jacopo.corbe...@gmail.com

WYMeditor MediaWiki integration:
http://www.mediawiki.org/wiki/Extension:MeanEditor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Eugene Zelenko
Hi!

On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett agarr...@wikimedia.org wrote:
 The advantage of this clear separation is that writing an API module
 is very simple, and it can be called internally, too!

I think will be good idea to use API internally (not only have
possibility to call), as result code will have more testing and
coverage.

Eugene.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread John Doe
thanks, I take this as the first step in creating global preferences?

On Fri, Apr 24, 2009 at 9:36 AM, Eugene Zelenko eugene.zele...@gmail.comwrote:

 Hi!

 On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrett agarr...@wikimedia.org
 wrote:
  The advantage of this clear separation is that writing an API module
  is very simple, and it can be called internally, too!

 I think will be good idea to use API internally (not only have
 possibility to call), as result code will have more testing and
 coverage.

 Eugene.

 ___
 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] New preferences system

2009-04-24 Thread Mohamed Magdy
On Fri, Apr 24, 2009 at 5:59 AM, Andrew Garrett agarr...@wikimedia.orgwrote:

 I've branch-merged the new preferences system that I've spent the last
 few weeks developing.

 On the outside, you probably won't notice any difference except a few
 bugfixes, but the internals have undergone a complete rewrite.

 All of the actual preference definitions and utility functions have
 been separated out into Preferences.php, which holds all business
 logic for the new system. The UI and submission logic for the system
 is done in SpecialPreferences.php, which, now only a hundred lines
 long, wraps a generic class I've written to encourage separation of
 business and UI logic called 'HTMLForm'.

 The advantage of this clear separation is that writing an API module
 is very simple, and it can be called internally, too!

 Extensions must now hook GetPreferences instead of the existing hooks
 (which were too low-level to maintain compatibility with), I've
 updated all extensions used on Wikimedia. This new hook allows you to
 put preferences wherever you want, and a new preference can be added
 in less than ten lines of code, rather than the hundred-line nightmare
 that was required in the previous iteration.

 I'd like to look towards trimming some of the existing preferences
 that are no longer relevant, and adding new preferences as common
 sense dictates.

 Feedback, praise and criticism regarding the changes is certainly welcome!

 --
 Andrew Garrett
 Sent from Sydney, Nsw, Australia

 ___


You are so useful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Alexandre Emsenhuber

Le 24 avr. 09 à 16:15, John Doe a écrit :

 thanks, I take this as the first step in creating global preferences?

Global preferences were added with this rewrite. There is just a  
checkbox saying use these preferences on all projects at the bottom  
of Special:Preferences.

Alexandre Emsenhuber (ialex)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Brian
Is an autoconverter feasible?
There are many, many extensions guys!

On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett agarr...@wikimedia.orgwrote:

 On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
 gerard.meijs...@gmail.com wrote:
  Hoi,
  How much work do you think it will be to repair an extension that needs
  repair ? For someone who knows the code and for someone who just has to
  repair his one extension ??

 It's a reasonably simple fix. Here's an example: [1]

 Essentially, all you need to do is remove your existing preferences
 code, hook GetPreferences, and add your preference to the array. I'll
 be posting documentation as to the format of preference entries
 tomorrow, but for now you can look at the examples in
 includes/Preferences.php.

 [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690

 --
 Andrew Garrett
 Sent from Sydney, Nsw, Australia

 ___
 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] New preferences system

2009-04-24 Thread Chad
And the vast vast majority don't use preferences. I don't think it'll
be a huge issue. The extensions that are broken and people use
will quickly be found and fixed.

-Chad

On Fri, Apr 24, 2009 at 12:43 PM, Brian brian.min...@colorado.edu wrote:
 Is an autoconverter feasible?
 There are many, many extensions guys!

 On Fri, Apr 24, 2009 at 9:53 AM, Andrew Garrett agarr...@wikimedia.orgwrote:

 On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
 gerard.meijs...@gmail.com wrote:
  Hoi,
  How much work do you think it will be to repair an extension that needs
  repair ? For someone who knows the code and for someone who just has to
  repair his one extension ??

 It's a reasonably simple fix. Here's an example: [1]

 Essentially, all you need to do is remove your existing preferences
 code, hook GetPreferences, and add your preference to the array. I'll
 be posting documentation as to the format of preference entries
 tomorrow, but for now you can look at the examples in
 includes/Preferences.php.

 [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690

 --
 Andrew Garrett
 Sent from Sydney, Nsw, Australia

 ___
 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] New preferences system

2009-04-24 Thread Andrew Garrett
On Sat, Apr 25, 2009 at 1:46 AM, Gerard Meijssen
gerard.meijs...@gmail.com wrote:
 Hoi,
 How much work do you think it will be to repair an extension that needs
 repair ? For someone who knows the code and for someone who just has to
 repair his one extension ??

It's a reasonably simple fix. Here's an example: [1]

Essentially, all you need to do is remove your existing preferences
code, hook GetPreferences, and add your preference to the array. I'll
be posting documentation as to the format of preference entries
tomorrow, but for now you can look at the examples in
includes/Preferences.php.

[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49690

-- 
Andrew Garrett
Sent from Sydney, Nsw, Australia

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Thomas Dalton
2009/4/24 Jacopo Corbetta jacopo.corbe...@gmail.com:
 An existing example of us providing users with such an option however
 can be seen in the ability to turn various editing-related gadgets such
 as wikiEd. I think this shows that should a more visual editing
 interface become able to be deployed, we certainly would make it optional.

 Exactly. Each editor has its own incompatible setting which allows it
 to be turned on or off. Basically, each extension assumes it is going
 to be the one and only one editor for the wiki. If you install more
 than one, things will break. A unified preference might have been
 useful. Anyway, no big deal.

I don't believe any WYSIWYG (or close to) editor that exists for
MediaWiki is good enough that you can completely avoid editing the
wikitext directly (in order to do complicated stuff), that means you
can't use one and only one editor unless that editor is the default
wikitext editor.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Soxred93
Keep in mind that when MediaWiki is developed, the best interests of  
Wikimedia are in mind. Wikimedia takes priority on MW development.


X!

On Apr 24, 2009, at 4:02 PM [Apr 24, 2009 ], Jacopo Corbetta wrote:


Many wikis use MediaWiki beside Wikipedia.




PGP.sig
Description: This is a digitally signed message part
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New preferences system

2009-04-24 Thread Gerard Meijssen
Hoi,
How much work do you think it will be to repair an extension that needs
repair ? For someone who knows the code and for someone who just has to
repair his one extension ??
Thanks,
  GerardM

2009/4/24 Brian brian.min...@colorado.edu

 How many non-WMF extensions will this break?

 On Thu, Apr 23, 2009 at 9:59 PM, Andrew Garrett agarr...@wikimedia.org
 wrote:

  I've branch-merged the new preferences system that I've spent the last
  few weeks developing.
 
  On the outside, you probably won't notice any difference except a few
  bugfixes, but the internals have undergone a complete rewrite.
 
  All of the actual preference definitions and utility functions have
  been separated out into Preferences.php, which holds all business
  logic for the new system. The UI and submission logic for the system
  is done in SpecialPreferences.php, which, now only a hundred lines
  long, wraps a generic class I've written to encourage separation of
  business and UI logic called 'HTMLForm'.
 
  The advantage of this clear separation is that writing an API module
  is very simple, and it can be called internally, too!
 
  Extensions must now hook GetPreferences instead of the existing hooks
  (which were too low-level to maintain compatibility with), I've
  updated all extensions used on Wikimedia. This new hook allows you to
  put preferences wherever you want, and a new preference can be added
  in less than ten lines of code, rather than the hundred-line nightmare
  that was required in the previous iteration.
 
  I'd like to look towards trimming some of the existing preferences
  that are no longer relevant, and adding new preferences as common
  sense dictates.
 
  Feedback, praise and criticism regarding the changes is certainly
 welcome!
 
  --
  Andrew Garrett
  Sent from Sydney, Nsw, Australia
 
  ___
  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] New preferences system

2009-04-24 Thread Brian
I am just hoping to prevent a repeat of ParserPP.

On Fri, Apr 24, 2009 at 2:56 PM, Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
 wrote:

 On Fri, Apr 24, 2009 at 4:23 PM, Soxred93 soxre...@gmail.com wrote:
  Keep in mind that when MediaWiki is developed, the best interests of
  Wikimedia are in mind. Wikimedia takes priority on MW development.

 Not as a general rule.  If we really didn't care about third-party
 users, we'd require the very latest version of PHP (since Wikimedia
 uses it), write large chunks of the software in other languages
 (Wikipedia has Python installed), and so on.  The suggestion to allow
 embedded Lua in templates seems not to be happening primarily because
 it would make Wikipedia content unusable by third parties on shared
 hosting.

 Although development of MediaWiki tends to focus primarily on
 Wikimedia's needs, it does *not* do so if that would significantly
 hurt MediaWiki's utility to third parties.  Part of Wikimedia's goals
 is to make its content as useful as possible to third parties.  That
 applies to MediaWiki insofar as it's a Wikimedia project, and doubly
 so insofar as it's needed to effectively use content from Wikimedia's
 other projects like Wikipedia.

 On Fri, Apr 24, 2009 at 4:25 PM, Brian brian.min...@colorado.edu wrote:
  What does this have to do with not horribly breaking many extensions at
 the
  same time? The WMF has cultivated an extension ecosystem and it makes
 sense
  to protect it.

 Do you have evidence that many extensions are, in fact, horribly
 broken?  And if so, that they can't be easily fixed?

 ___
 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] New preferences system

2009-04-24 Thread Aryeh Gregor
On Fri, Apr 24, 2009 at 4:59 PM, Brian brian.min...@colorado.edu wrote:
 I am just hoping to prevent a repeat of ParserPP.

A *lot* more extensions use parser-related stuff than preferences.  In
any event, the upheaval of ParserPP was probably necessary given what
it sought to achieve.  That sort of thing happens from time to time --
it's not feasible for extensions with access to so many hooks and
methods to just work forever.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Platonides
Alex wrote:
 Extensions can add their own preferences more easily now. Adding a
 default preference to turn off a feature that doesn't yet exist in
 MediaWiki core doesn't make much sense.

A preference name could be reserved to be consistently used by all
alternate editors.
Anyway, IMHO any alternate editor should offer an option to disable it
directly on the edit page, regardless of a preference which would define
don't appear by default.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Chad
APIs change in incompatible ways sometimes. When it's avoidable, that's
great. Andrew seems to indicate that in this case, it wasn't possible to keep
the hooks identical to how they were. That's why its best to keep extensions
in svn so developers can easily spot and fix issues like this when they arise.

-Chad

On Fri, Apr 24, 2009 at 6:50 PM, Brian brian.min...@colorado.edu wrote:
 Whatever happened to object-oriented programming and abstraction? Why can't
 you define and provide a consistent API?

 On Fri, Apr 24, 2009 at 3:06 PM, Aryeh Gregor
 simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
 wrote:

 On Fri, Apr 24, 2009 at 4:59 PM, Brian brian.min...@colorado.edu wrote:
  I am just hoping to prevent a repeat of ParserPP.

 A *lot* more extensions use parser-related stuff than preferences.  In
 any event, the upheaval of ParserPP was probably necessary given what
 it sought to achieve.  That sort of thing happens from time to time --
 it's not feasible for extensions with access to so many hooks and
 methods to just work forever.

 ___
 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] New preferences system

2009-04-24 Thread Trevor Parscal
On 4/24/09 4:38 PM, Alex wrote:
 While backwards compatibility is nice, if it stands in the way of
 improving something that needs improvement, the improvement should take
 priority
Indeed - even Microsoft eventually abandoned Windows 3.1 
compatibility... And more recently compatibility with all software in 
existence.

- Trevor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] New preferences system

2009-04-24 Thread Andrew Garrett
On Sat, Apr 25, 2009 at 3:08 AM, Brion Vibber br...@wikimedia.org wrote:
 On 4/24/09 6:36 AM, Eugene Zelenko wrote:
 On Thu, Apr 23, 2009 at 8:59 PM, Andrew Garrettagarr...@wikimedia.org  
 wrote:
 The advantage of this clear separation is that writing an API module
 is very simple, and it can be called internally, too!

 I think will be good idea to use API internally (not only have
 possibility to call), as result code will have more testing and
 coverage.

 Client-side JavaScript UI code can use the API to reach the backend, but
 I don't see much benefit to trying to use the API on the PHP UI end;
 it'll generally just be awkward.

 API code should rarely have to do any serious DB or processing work
 itself; it should be calling the backend model/controller-level interface.

I mean, of course, that the back-end business logic interface can be
called internally, not that the API can be called internally.

-- 
Andrew Garrett

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New preferences system

2009-04-23 Thread Andrew Garrett
I've branch-merged the new preferences system that I've spent the last
few weeks developing.

On the outside, you probably won't notice any difference except a few
bugfixes, but the internals have undergone a complete rewrite.

All of the actual preference definitions and utility functions have
been separated out into Preferences.php, which holds all business
logic for the new system. The UI and submission logic for the system
is done in SpecialPreferences.php, which, now only a hundred lines
long, wraps a generic class I've written to encourage separation of
business and UI logic called 'HTMLForm'.

The advantage of this clear separation is that writing an API module
is very simple, and it can be called internally, too!

Extensions must now hook GetPreferences instead of the existing hooks
(which were too low-level to maintain compatibility with), I've
updated all extensions used on Wikimedia. This new hook allows you to
put preferences wherever you want, and a new preference can be added
in less than ten lines of code, rather than the hundred-line nightmare
that was required in the previous iteration.

I'd like to look towards trimming some of the existing preferences
that are no longer relevant, and adding new preferences as common
sense dictates.

Feedback, praise and criticism regarding the changes is certainly welcome!

-- 
Andrew Garrett
Sent from Sydney, Nsw, Australia

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l