Difference between revisions of "DPL:Requests for new features"
(→Reply #2) |
(Template field output) |
||
Line 4: | Line 4: | ||
::''Old requests (which have been resolved) can be found in the [[DPL:Requests for new features Archive]]. | ::''Old requests (which have been resolved) can be found in the [[DPL:Requests for new features Archive]]. | ||
+ | |||
+ | |||
+ | ==Template field output== | ||
+ | Is it possible to output the unescaped wikimarkup (so it actually works as on pages that use the template) in DPL output? I want to create a DPL table that has same links as articles do that use the template in them which is also called in the DPL table. -[[User:Eep²|Eep²]] 06:56, 26 July 2007 (CEST) | ||
Revision as of 05:56, 26 July 2007
Contents
- 1 Template field output
- 2 User-friendlines
- 3 Don't replace underscores by spaces
- 4 Be PostgreSQL compliant
- 5 Multiple columns with headingmode
- 6 rss feed from dpl
- 7 Create a special page for searching pages with DPL
- 8 display Table of Contents for an article
- 9 Better error handling
- 10 Output Format suited for SpecialExport
- 11 Hook based data exchange between extensions
- Please add requests for new features at the beginning of this document. If possible make syntax suggestions and give an example for the desired behaviour!
- Old requests (which have been resolved) can be found in the DPL:Requests for new features Archive.
Template field output
Is it possible to output the unescaped wikimarkup (so it actually works as on pages that use the template) in DPL output? I want to create a DPL table that has same links as articles do that use the template in them which is also called in the DPL table. -Eep² 06:56, 26 July 2007 (CEST)
User-friendlines
DPL talk:Manual - DPL Special Page with Parameters#User-friendliness -Eep² 11:42, 25 July 2007 (CEST)
Don't replace underscores by spaces
Request
I'm running a programming language MediaWiki for which DPL is most suited. But listing functions with spaces instead of underscores looks a bit weird. Is it possible to tell DPL to not replace underscores in the links by spaces and to replace spaces in the links by underscores?
Something like:
<DPL> category = functions replacespaces = true </DPL>
which would output:
* [[my_func]] * [[my_other_func]]
instead of:
* [[my func]] * [[my other func]]
It would mean a great deal to me and the community. Thanks in advance.
--Sandman 02:39, 25 July 2007 (CEST)
PS: If this can be setup somewhere in regular MediaWiki, please inform me of it.
Reply
Have you seen the 'replaceintitle' option? Maybe you could use 'mode=userformat' and [[%TITLE%]]. Although this will probably not work with namespaces. If you can´t get along with this approach, let me know.
Regarding DPL on Wikipedia etc.: I am not familiar with the kind of lobbying that would be required for this. But I think it could be quite helpful in almost every wiki. See my note on bugzilla. Maybe you want to add a statement there?
- Gero 05:33, 25 July 2007 (CEST)
Reply #2
I created an article with underscores in its name. Normally this would give a result like
Please note that the link itself still contains the underscore. DPL converts underscores to spaces as this is common expectation in wikis. You can revert this behaviour using 'replaceintitle'. Note that you have to use the html special name for the underscore (otherwise your substitution will be overwritten by DPL). So your code should look like this:
<pre> <dpl> titlematch=%underscore replaceintitle=/ /,_ </dpl> </pre> It will produce the result
And I guess, that´s what you wanted. This solution will also work with articles in all namespaces.
- Gero 05:55, 25 July 2007 (CEST)
Response
Yes, this is what I needed, thanks! Sorry it was already featured; too bad MediaWiki itself doesn't seem to have this feature. I've left a statement at the location you requested with nothing but praises. ;-)
- --Sandman 17:54, 25 July 2007 (CEST)
Be PostgreSQL compliant
Request
As of DPL 1.1.7, usage of DPL in a PostgreSQL-based MediaWiki requires further effort, which I describe in DPL:Manual - DPL with PostgreSQL.
- I don't know if there is a common syntax between MySQL and PostgreSQL for the database functions - if not, my solution is easy to install.
- But the need for a patch is really nasty. I think with my patch, DPL still works with MySQL as well. If so, could you kindly incorporate it.
I'd be curious if you consider this a feature request or a bug report…
Multiple columns with headingmode
Request
Maybe this is doable already but I couldn't figure it out: I want to use ordermethod=category,sortkey and headingmode but I want it in multi-column form (or have more user control regarding the output format). There's a column parameter but it doesn't seem to work with headingmode. Another possibility is if I could use mode=userformat and somehow simulate the behavior of multi-column headingmode. I realize that the columns might not be all the same length as there could be different number of pages in each category. I think the simplest implementation would be to put one category heading in each column and ignore the list under each category.
rss feed from dpl
Request
A DPL might also have an according RSS feed. For example, a calendar might give a feed with the upcoming events from now on. --Eiland 09:30, 16 April 2007 (CEST).
Response
I haven´t worked with RSS generation so far. Is there a php library or a mediwiki module for that purpose? --Gero 22:08, 23 April 2007 (CEST)
- Plenty of MediaWiki Extensions for RSS... should be easy to integrate with DPL :) --141.14.26.126 13:16, 29 April 2007 (CEST)
- Which one would you suggest? Can you do the integration? Gero 20:12, 2 May 2007 (CEST)
Request
I have a similar request... Make each DPL into an RSS feed! --Dmb 11:20, 1 June 2007 (CEST)
Wait... that was me talking ... I just recognized my IP... (oh my memory!)
Well... you could start by looking here...
- http://meta.wikimedia.org/wiki/User:Mafs/RSS
- http://meta.wikimedia.org/wiki/RSS_into_Wiki
- http://www.mediawiki.org/wiki/GISWiki/RSS
That should certainly help with the details. Unfortunately I cannot do the integration myself or I would happily do it immediately. Thanks for the brilliant product and keep up the good work! --Dmb 11:24, 1 June 2007 (CEST)
Create a special page for searching pages with DPL
Request
- It could be interesting to have a special page that does a search based on a DPL. The DPL parameters would be set in a form (that could be enhanced in time with some common values).
- The current search functionality in Mediawiki is quite limited, and DPL adds much power here.
- Example: I want all the pages edited by user X in category Y and category Z, etc...
- This is just a random idea, as I sometime had to query by editing a page and doing a preview without saving. Being able to do a DPL search and get a result set on a page without having to edit a page would be nice.
--Ycombarnous 14:55, 10 April 2007 (CEST)
Reply
- I created the base frame for such a "specials" page. But I will not have time to work on it. See the source archive, and feel free to start coding. -- Gero 19:44, 21 April 2007 (CEST)
- I know it's quite a lot of work. I will try and make a static proposal for the page, and work on it as time allows. thanks. --Ycombarnous 10:32, 23 April 2007 (CEST)
- I also thought this would be useful so I implemented something very simple and more general. It's a special page that is a generic wikitext parser (and so works with DPL and any other parser extension). It lets you bookmark a link to a search query via DPL for example. See here for an example. The source code is here. --Austin
- This looks interesting, Austin! Maybe we can build a simple solution based on your extension --Gero 20:17, 26 April 2007 (CEST)
- Well, there is a first trial version of DPL-special-page available with version 1.1.4. I started with the code from Austin and added my ideas. Have a look! --Gero 14:48, 30 April 2007 (CEST)
- It's a good start, but I was actually thinking more to someting like Bugzilla boolean charts (go to a bugzilla install, in "advanced search", and see the section at bottom (called Advanced Searching Using Boolean Charts). Basically, you have per line:
- the field you want to set a value on
- the type of matching you look for (would correspond to match / in / not in for DPL)
- and finally your value
- in addition, you can add as many lines as you want
- It would require some javascripting telling for each field the corresponding matching available, plus if several lines use the same field with different criteria, a concatention would be needed. What do you think? --Ycombarnous 17:07, 30 April 2007 (CEST)
- What you described would certainly be a much better way to implement it. I was only looking for a "developer´s help tool" which offers the big variety of available parameters and allows a quick trial&error-cycle. I will not find time to do anything beyond that, I´m afraid.
- Gero 20:10, 2 May 2007 (CEST)
Simple Forms extension
Extension:SimpleForms can work very well with DPL, it's still under development, but the DPL example on the page works and is a basis for making more complex query forms/reports. OrganicDesign main page shows the example working. --Nad 03:31, 29 April 2007 (CEST)
display Table of Contents for an article
Request
the incudepage feature could be enhanced to include the TOC only; a %TOC% variable would ebe useful ...
Better error handling
"%DPL-1.2.5-WARNING: No results!" is a tad bit vague (note the sarcasm). -Eep² 12:40, 24 July 2007 (CEST)
- What do you expect instead? Did you notice the 'noresultsheader' option? Gero 20:30, 24 July 2007 (CEST)
- Something like "no noresultsheader specified" or something. Even if you submit a default "report" (without changing anything), DPL just goes right back to the same screen without even saying anything is wrong. Basic javascript error-checking would be good without requiring a many server-hit response. Why does DPL cause so many server hits anyway? Seems like every page takes at least 10 hits before it finally shows up anyway (status bar flashes like mad)... -Eep² 21:44, 24 July 2007 (CEST)
Output Format suited for SpecialExport
Would it be possible to have an 'output format' that would be more suited for 'cut and pasting' to Special:Export ?
The use-case is the following:
- User creates a DPL query on 'My Pages To Export'
- User saves the page 'My Pages To Export'
- User views the said page & 'cut and paste' the result from the view into 'Special:Export'
- User exports pages
Reply (with example)
This should be fairly easy to do. Try something like{{#dpl:mode=userformat|titlematch=Ca%|listseparators=,\n %PAGE%,}}
Note the leading colons and the slashes for subpages. I think you could paste this result directly into the export textarea.
Cache Demo 2 Cannot perform logical operations Calendar zh-tw/Demo Call extension Cache API Cache Demo 1 Calendar zh-tw Calendar Cameroon Talk:Calendar zh-tw Talk:Call extension Talk:Cache API Talk:Calendar User:Capmo User talk:Capmo :File:Calendarerror.jpg :File:Catlist error msg 001.png :File:Calendar templates-20071124.xml Template:Calendar link zh-tw Template:Car.list Template:Calendar navigation Template:Category with count Template:CatTreeSub Template:Calendar anchor Template:Category handler/numbered Template:Car Template:CatTree Template:Calendar/MonthStartThu Template:Calendar/MonthStartTue Template:Calendar/MonthStartWed Template:Calendar/MonthStartFri Template:CategoryGallery Template:Calendar/MonthStartMon Template:Calendar/MonthStartSat Template:Calendar/MonthStartSun Template:Category handler/blacklist Template:Calendar link Template:Calendar month Template:Calendar month zh-tw Template:Category handler Template:CalendarSingle Template:Catgraph Template:CalendarSingle zh-tw Template:Catlist1 Template:Catlist Template:Catlist zh Template:Catlist/zh Template:Catlist/zh 2 Template talk:Calendar link Template talk:CatTree Template talk:Calendar month Template talk:CalendarSingle Template talk:Catlist :Category:Cat d'Test :Category:Café :Category:Cat 2 :Category:Cat 1 :Category:Cat 11 :Category:Cat 12 :Category:Car :Category:Category :Category:Café d'Anvers :Category:Calendar Templates DPL:Catlist DPL talk:Catlist Issue:Calendar - combine create event and dayview Issue:Cannot include a template call that uses a 2nd template variable Issue:Calendar : Current event + create event Issue:Caching on Mediawiki 1.13 Issue:Calendar create event bug Issue:Call - passing a variable twice Issue:Category names with ampersand not found? Issue:Category browsing with title from / until Issue:Calendar - without event template Issue:Call-time pass-by-reference Issue:Calendar - ical / template Issue:Call-time pass-by-reference dpl 1.7.9 mw 1.13 Issue:Call-time pass-by-reference deprecated Issue:Category=*somecategory combined with ordermethod=category,sortkey does not list subpages Issue:Calendar - range Issue:Category:New format symbols: %PREV% and %NEXT% Issue:Categorymatch=with apostrophe Issue:Can't call a EmbedVideo extension with the Parser function method Issue:Category option that does AND operation to multiple parameters Issue:Caching Issue:Call to a member function getPrefixedDBkey() on a non-object
Furthermore, it should not be too complicated to set up a nice little collection of GUI widgets which offer drop down boxes for categories to the user, etc..
See the comments above regarding the DPL special page.
I would be glad if somebody came up with a nice "My Pages To Export" page based on DPL. I am not sure whether you would really need a hook or php call level communication for that purpose...
- Gero 20:51, 24 July 2007 (CEST)
Hook based data exchange between extensions
Would it be possible to add a 'hook' (i.e. wfRunHooks) to DPL? Once a 'query' is finished executing, the result could be signaled to other interested extensions. A 'context id' would be required as potentially many queries could co-exist on the same page. I would suggest adding a parameter such as 'context=' OR just a linear incremental counter.
A 'no output' option would be great also - this way, if the query is really meant to be consumed by another extension, the user isn't distracted by the result from DPL directly. mw:user:jldupont
Reply
I do not have experience with creating hooks. There is a point in the code where the sql result set is ready. But be warned: The columns contained in the result set may vary depending on the options used. Generally speaking, DPL is a beast that has reached its saturation level of complexity ;-). I would more be in favour of a way where DPL produces some kind of csv output which is then fed into another extension. With mode=userformat this is fairly easy because you have complete control over the output. You can create csv or whatever format suits your own extension. This need not be wikitext nor need it be html or plain text - any kind of grammar is possible. For example you can use the result of one DPL statement as a parameter for another one, i.e. you can nest DPL calls. There is a good example for this: Wgraph:Example 4. Here the inner DPL query produces a pipe-separated list for the outer one.
So, the 'no output' you are looking for is already there. It´s called mode=userformat -- and it will take you some time to understand its power. Being the author I am still myself learning what you can do with DPL ;-)
The problem of multiple contexts is also solved by extension nesting. Maybe you do a little exeprimenting and then come up with another comment?
- Gero 21:05, 24 July 2007 (CEST)