libreplanet-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libreplanet-dev] Fwd: fsf groups extension patch


From: John Sullivan
Subject: Re: [Libreplanet-dev] Fwd: fsf groups extension patch
Date: Fri, 27 Mar 2009 16:19:18 -0400
User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux)

(Can you make sure when you reply that you keep the list in?)

Peter <address@hidden> writes:

>> Hm, okay. I'll have to think about this more; part of what we are trying
>> very hard to avoid here is custom code. We want to stick as closely as
>> possible to the Mediawiki upstream, so that we can continue to be
>> current and take advantage of all the extensions that are out there. Is
>> there any possibility of getting these functions added upstream?
>
> The custom code fits into the extension system provided by mediawiki. So it 
> shouldn't be affected by upgrades. It is a standard wiki with custom 
> extensions. I haven't tried to get the extensions 'officially' approved (like 
> the calendar) because as you point out, its not really the mediawiki way.
>

Wouldn't it make more sense to package these up as extensions and get
them distributed along with other extensions? That way, other people
might contribute to maintaining them, and they would at least have a
chance at being part of the upgrade path. I'm sure the extension system
changes from time to time and breaks things?

>>
>> I'm not certain any more that we should be using subpages that rely on /
>> to create namespaces. From what I'm being told that's not really the
>> Mediawiki way of doing things.
>
> 'subpages that rely on / to create namespaces' <-- I don't understand. 
> Namespaces are created statically by the webmaster and are not influenced by 
> page creation.
>
> To back up a bit: mediawiki _developers_ created a wiki that can construct 
> pages as a tree data structure. This is a typical and efficient software data 
> structure for both storing and accessing _related_ information. However, the 
> developers did not provide all the functions necessary to manipulate the 
> structure efficiently. Consequently, mediawiki users seldom create related 
> pages in a tree structure because it is hard to maintain, so there is an 
> existing culture to avoid subpages.
>
> I have (hopefully) added the missing functions, so using subpages is as easy 
> to use as single pages. Now people can add related pages as a tree structure, 
> so the content can be navigated in a relational way. In this sense, it is 
> _more_ consistent with the _developers_ idea of the wiki, than the culture. 
> The page content and page relationship are merged and the wiki has a 
> consistent look-and-feel to it.
>

Okay, I'm sorry to continue being dense about this, but I need a *short*
example that demonstrates what these functions do. It would help a lot
to see a concrete example of something that is hard to do with default
Mediawiki that these functions solve. I am getting closer to
understanding I think, but not quite there :).

Thanks,
-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6




reply via email to

[Prev in Thread] Current Thread [Next in Thread]