Last modified: 2011-04-14 15:13:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9559 - aggregated Labelled Section Transclusion
aggregated Labelled Section Transclusion
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 5881
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-11 12:48 UTC by Luke Kenneth Casson Leighton
Modified: 2011-04-14 15:13 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Luke Kenneth Casson Leighton 2007-04-11 12:48:00 UTC
dear wikimedians,

thank you for _already_ having done the LST enhancement :)

i have a second (just as important) idea - _reverse_ LST.

basically it goes like this:

 * place a marker in a page {{LSTtarget:<name>}}

 * in any page, place a tag {{reverseLST:<page>#<name>:<optional numbering N[.N]*>}}
   and obviously its corresponding end tag

 * have a special tag which allows the numbering optionally given in the tag
   to be displayed inline, in the "target" marker page (LSTtarget:<name>)

the purpose is this:

 i am currently doing some research.  the research is complex.
 i am finding links all over the place.
 i have a list of unsorted things to resolve,
 and i also have a list of "posts to keep an eye on".
 this list i want to split up into the individual
 research pages AND i want them to appear on the "main" page.

 without duplication.

 by placing an {LSTtarget:monitor_postings} tag on the "main" page,
 and then by placing this on my UbuntuResearch page:

{{reverseLST:ThingsToDo#monitor_postings}}
 * http://forums.ubuntu.org something really stupid i said on ubuntuforums
{{endreverseLST:ThingsToDo#monitor_postings}}

 i expect there to be created a bullet-point of a single item
 on the UbuntuResearch page **AND** a bullet-pointed list comprising
 ALL monitored postings to appear on the "main" page.

 the purpose of adding a section number is, obviously, so that the
 list can be sorted and, if desired, numbered.  or auto-numbered.
 _whatever_.

 at least it's a start.

 but bear in mind that it might be useful to have "outsourced" scripts
 which are run whenever a page is edited (see ikiwiki concept, which is
 a much better way to create a wiki) which can do some pre-parsing for
 you to generate the pages.

 ( extensions on steroids, basically, but not restricted to php )

 you are in danger of creating a programming language (i've already seen
 enough ifs and buts and stuff) and doing that is _always_ a stupid idea,
 as can clearly be seen by the extensions.conf abominations that are
 required for asterisk.

 cut the shit and use a proper programming language.

 l.
Comment 1 Rob Church 2007-04-11 14:56:11 UTC
Please provide a proper feature request with a decent explanation of what's
being asked for and decent examples of how it should work, because what I see
above is a very loose and not particularly clear request, and I don't come away
with any understanding of your problem or the requested addition.

Please also limit feature requests to the request, and not random musings on
other parts of MediaWiki; our bug tracker is not the place to begin any sort of
dialogue on your objection to the parser functions slope, much as I agree with
some of your sentiments.
Comment 2 Luke Kenneth Casson Leighton 2007-04-11 16:04:29 UTC
(In reply to comment #1)
> Please provide a proper feature request with a decent explanation of what's
> being asked for and decent examples of how it should work, because what I see
> above is a very loose and not particularly clear request, and I don't come away
> with any understanding of your problem or the requested addition.

 sorry!

 ok.

 this is a quite complex thing to describe, and i do not know the language
 that you use / terminology that you use, so please be patient whilst we thrash
 this out: it might take a few rounds.

 the problem that i want to solve is this: i want sections of wiki content to
 be "amalgamated" (duplicated) into one target.

 example: i have multiple pages on which i am maintaining http links as part of
 my research.  i want all of those links to be merged into ONE location WITHOUT
 i repeat WITHOUT having to resort to stupid pointless cut/paste duplication.


 another way to put it is by analogy: one-to-many is to LabelledSectionInclude
 as many-to-one is to InverseLabelledSectionInclude.  so, where LST can be used
 to drag/duplicate ONE section of a page in to MANY locations, i want MANY
 sections on MANY pages to be drag/duplicated into ONE section of a page.

 hence the need for specifying some sort of ordering on the sections being
 "dragged in".

 (actually, it's many-to-many but that's another story)

 so.

 ResearchPage1 content:

{{reverseLST:ThingsToDo#monitor_postings}}
* http://forums.ubuntu.org something really stupid i said on ubuntuforums
{{endreverseLST:ThingsToDo#monitor_postings}}

 ResearchPage2 content:

{{reverseLST:ThingsToDo#monitor_postings}}
* http://lists.debian.org something even stupider i said on debian-devel
{{endreverseLST:ThingsToDo#monitor_postings}}

 PostsToKeepAnEyeOncontent:

  {LSTtarget:monitor_postings} 

results in the following html:

<ul>
<li /> http://forums.ubuntu.org something really stupid i said on ubuntuforums
<li /> http://lists.debian.org something even stupider i said on debian-devel
</ul>

and on ResearchPage1:

<ul>
<li /> http://forums.ubuntu.org something really stupid i said on ubuntuforums
</ul>

and on ResearchPage2:

<ul>
<li /> http://lists.debian.org something even stupider i said on debian-devel
</ul>

cool, huh? :)

now scale that up to 50 pages with over 200 links in total being amalgamated
from those 50 pages, and you start to appreciate why i certainly do not want
to be duplicating stuff all over the place.


> Please also limit feature requests to the request, and not random musings on
> other parts of MediaWiki; our bug tracker is not the place to begin any sort of
> dialogue on your objection to the parser functions slope, much as I agree with
> some of your sentiments.

 *lol* ok :)
Comment 3 Steve Sanbeg 2007-04-11 18:10:02 UTC
If I understand this, "aggregated" may be a better description than "reverse"

With LST, you transclude a specified section from a specified page.  It seems
like you want to get the specified section without specifying the page, by
getting it from all pages it appears on.

i.e. page1 has <section begin=agg/>some random wiki text
<section end=agg/>

page2 has <section begin=agg/>some more wiki text
<section end=agg/>

So you can do something like {{#lstall|agg}}

To get:
some random wiki text
some more wiki text
Comment 4 Luke Kenneth Casson Leighton 2007-04-12 06:44:32 UTC
(In reply to comment #3)
> If I understand this, "aggregated" may be a better description than "reverse"

 yeah, that's exactly it.

 imagine it like this: you have a btree, with back-pointers to the "parent" in each
 child node.

 LST is like the child-to-parent pointers.

 Agg is like the parent-to-child back-pointers.


 another way to put it: in advogato, there is the concept of Certification.
 in the XML documents for each user, _who_ you have Certified, and who has
 Certified _you_, are each stored in your profile.xml.

 LST is like the "who you have Certified".

 Agg is like the "who has Certified you".


Comment 5 Luke Kenneth Casson Leighton 2007-04-12 06:47:41 UTC
... of course, with each of the examples and analogies given, no ordering is
possible.

therefore it is necessary to _add_ some sort of hierarchical numbering scheme.

and one thing that would be very helpful there would be to have a _really_ special
"Edit" page which allows the aggregated content to be edited and then put back
in each of the pages from whence the aggregated content came!

now that _would_ blow people's minds!!!

meta-page-editing *argh*!

:)
Comment 6 Luke Kenneth Casson Leighton 2007-04-12 06:49:36 UTC
PLEASE DISREGARD that last comment from me, until such time as aggregated LST is
working, and in effect.

i'll raise a SEPARATE feature enhancement once the dust settles from agg-LST.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links