Yeh, I was actually surprised that there were no
abstract classes to base
extensions on, but this might actually be good if flexibility is needed - we
don't know what people would want to extend and at some level using abstract
class might reduce possibilities, although it this class is not mandatory,
then it's a good help for new developers.
I think starting with some code that people can reuse might be a good first
step to identifying the right structure of classes, although I have quite
little experience in extension development and there might be a good
approach that'll cover most of the cases.
With widgets (which I probably should announce with separate email with
thorough description) the idea was to separate the task of backend
development and front-end development since vast majority of widgets are
just some chunk of HTML and JS. There are still several tasks that backend
needs to do, but they all standardized and Smarty is doing most of the work
(I had very little idea about various templating frameworks and it was the
only one with some authority).
Sergey
On Sun, May 11, 2008 at 5:57 AM, DanTMan <dan_the_man(a)telus.net> wrote:
Your idea on widgets is actually a bit similar to
something I was
thinking about earlier on today.
There are a lot of extensions which do similar things. And a lot of
things which have a lot of variance to them.
Then there is a fair bit of variance to how certain things are done and
handled with extensions.
Honestly, some of this makes the idea of a 'Extension Installer' that
people propose to be a little tough.
For example, variables are used allot in extension files. However, most
of the time none of these are globalized.
As a result of this, it is impossible to delegate the inclusion of an
extension to a special function made to simplify the task.
So, instead we make the one installing the wiki use a cryptic
require_once statement. And delegate everything being done
to the extension itself forcing it to handle everything.
I did entertain the idea in my own time of using:
include extension('CheckUser');
^_^ Of course, that's a little bit of a visual hack I came up with.
'extension' would be an actual function. Designed with the task of
outputting a string for inclusion of an extension.
Nonexistant extensions and such would be handled by a die statement
inside of it... Or even better, I could let a configuration
option make the function silently pass nonexistant extensions over by
passing the name of an empty but existing file and write out
to the debug logs that the extension could not be loaded.
;) If you get the thought, it would mean that accidentally removing the
files for an extension wouldn't crash your site, it would just
silently work without the extension.
But, that's just a little tangent thought. And it's extremely limited,
like how it is limited to only a file, and is required to output that file
even if it can't fine one.
My thought was a refactoring on how extensions are actually done. Rather
than making extensions a tangent thought where we give
them a bunch of hooks they can subscribe to, and beyond that do
extremely little to interact with them and simplify how much the
extensions actually need to do on their own.
I thought of actually integrating the notion of an 'extension' into core
a lot more.
One of the ideas was an Extension class.
- An extension subclasses the Extension class with it's own class to
identify itself.
- Because classes are outside of the scope limitations, we can delegate
inclusion of files to anywhere, including functions which
are easier for users to understand.
- We can have the extension store it's configuration options inside of
it's own object.
-- This makes sure nothing can ever collide with other extension
variables or core variables.
-- The Extension's class can pass itself into any class that it creates.
And as a result let them access the configuration options to use.
- The core Extension class would be preloaded with a number of useful
methods for extensions to use.
While we're at it, there was something that I discussed with
TimStarling. Rather than using wfLoadExtensionMessages, and being forced
to load every single one of them when we need to find a single message
for a MediaWiki: page. There is another potential way to get
messages which does not require us to load everything and reduce
performance.
A lot of extensions use prefixes. And that is a real fair bit of them.
Nearly every one in SVN has it's own unique way to start the names
of it's own messages unless it's using a basic word.
There is potential for an extension to register a message prefix with
the system. And then, when MediaWiki needs to find a message,
instead of loading all the messages for every extension it would check
the name of the message for a registered prefix, and load the messages
for the extension if needed. Tim even tells me of some sort of text tree
I think it was, which would suit this better than iterating over and
entire
array to search for a prefix.
As for identification of the extension itself. We could put that kind of
data into a method in the extension's class, and instead of using a
global set every load, and unreliable if extensions don't identify
themselves. We could even list on Special:Version "X unidentified
extensions installed."
And, we can even reduce how much is loaded. A lot of extensions repeat
functionality of certain things. One type of thing for example is pure
Parser Function
extensions. Ones made purely to create a new ParserFunction.
We could do a number of things with this kind of extension. Firstly, we
could subclass the Extension class and preload important types of
configuration which
these extensions would normally do on their own. Meaning that the actual
work needed for extensions this simple would be reduced.
And there's something even better. When do we even need parser
functions? We need them in the Parser, we need them in the parser, we
list them
on Special:Version... But honestly, we don't need to load them every
page view. And that's what a lot of extensions using the body file
tactic do.
In fact... We go and register ParserFunctions by making a call to
$wgParser for each and every one of them. What if all the things on the
page which needed
to be parsed were actually already in the cache? We'd have to go and
unstub the Parser class just to register a number of parser functions
which aren't going to
be used. And honestly, while there are still a few messages which are
parsed for each page load, it would be quite possible to cache those
with the page title
and make it so that at some times when viewing MediaWiki you don't need
the parser to ever be unstubed.
This could be said for a fair number of different things. Why load
everything, when only one of those things is needed? So we could
potentially group out different
things that extensions may add and have the extension setup callbacks of
things to load. And so we'll only load various parts of the extension if
they are actually needed.
~Daniel Friesen(Dantman) of:
-The Gaiapedia (
http://gaia.wikia.com)
-Wikia ACG on
Wikia.com (
http://wikia.com/wiki/Wikia_ACG)
-and
Wiki-Tools.com (
http://wiki-tools.com)
Sergey Chernyshev wrote:
Dan,
I think it's perfectly fine to create this documentation within
MediaWiki.org - there is no need for special features on the site, just
documentation, right? It seems to be a natural place to search for such
information.
As for code generator, I think it's an overkill to start with such
complex
thing - getting just boilerplates is a good short
first step which will
benefit generator once code stabilizes. Moreover, code can be included
right
into wiki pages instead of SVN to minimize
learning curve because people
who
use SVN are already less prone to coding mistakes
then people who just
copy/paste and those are the most important people to target.
I also created Widgets extension partially to help eliminate those
extensions that just print out some HTML based on the input without
employing much of the logic - they all can be replaced with templateing
language instead (Widgets uses Smarty). I already converted my
SlideShare
extension to SlideShare widget to start with.
I'll be happy to be a user of such documentation and best practices
documents and help "debug" them ;)
Sergey
On Fri, May 9, 2008 at 3:15 PM, DanTMan <dan_the_man(a)telus.net> wrote:
> Unfortunately there really isn't good documentation on creating
> extensions for MediaWiki. And a lot of the existing documentation is
> badly out of date. (This is kind of the reason why we still see a lot
>
of
> use of the SpecialPage::addPage method when
it has been depreciated).
>
> Actually, JaeSharp once poked me to help start on creating a good
>
source
> of help. I've got SMW and a good setup,
cept I need to get God to watch
> PHP to keep it alive. I could create a developer help wiki for
>
MediaWiki.
> ^_^ As for the boilerplate code... Honestly,
JaeSharp was planning on
> creating a kind of generator code... Like how rails has generators to
> create scaffolding (models, views, and controllers which already work
> out of the box).
> That way extension developers could simply run a script with the name
>
of
> their extension, and a bit of input on what
kind of things they are
> using... Do they want it to not output i18n files, any special pages to
> create, any parserfunctions that need a i18n.magic, or extension class.
> And create relevant files from that.
>
> ~Daniel Friesen(Dantman) of:
> -The Gaiapedia (
http://gaia.wikia.com)
> -Wikia ACG on
Wikia.com (
http://wikia.com/wiki/Wikia_ACG)
> -and
Wiki-Tools.com (
http://wiki-tools.com)
>
> Sergey Chernyshev wrote:
>
>
>> Dan, thanks for this long overview, is there a wiki page on
>>
>> that describes all this? If not, I'll
just refactor your email to a
>>
page
> if
>
>
>> you don't mind.
>>
>> It probably also makes sense to maintain some boilerplate code as well
>>
so
> new
developers can have an easy start.
>
> Sergey
>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l