Last modified: 2011-04-14 15:13:19 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.
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.
(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 :)
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
(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".
... 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*! :)
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.
