Issue:Specific enhancements for 'table from template' DPL

Description:	Add flexibility to custom output format
Extension / Version:	DPL   /   1.6.0
Type / Status:	Change Request   /   reopened

Problem

Original change request:

Specific enhancements for 'table from template' DPL

I think a very commonly needed and natural use of the DPL is the 'table from template' DPL. I would like to suggest the following syntax to make it easier to

generate such DPL output...

...
incude = {Some template}:parameterOne
incude = {Some template}:parameterTwo
incude = {Some template}:parameterThree
tablehead =  Title,            One,            Two,            Three
tablebody = %TITLE%, %parameterOne%, %parameterTwo%, %parameterThree%
...

The above would generate a table of data for the named parameters passed to 'Template:Some template' in the included pages. I really really love the functions provided by DPL, I just find them hard to master! --Dmb 18:53, 18 September 2007 (CEST)

Reply

That´s almost exactly what will be in the next version! But The syntax will look like this:

...
include = {Some template}:parameterOne:parameterTwo:parameterThree
table   = ,, One, Two, Three

Creating pseudo variables for each column would add new complexity which I try to avoid.

Gero 20:13, 18 September 2007 (CEST)

I understand why keeping complexity to a minimum is important, but the above solution (clean though it is) is very rigid compared to the flexibility afforded by the use of pseudo variables. Imagine the following, parameterOne is information about the category of the page that I would like to wrap [[:Category:%p1%]], parameterTwo is an logo pointer that I would like to wrap [[Image:%p2%|200px]] and parameterThree is a website link that I would like to wrap [%p3% homepage]. None of this funn stuff is available via the above syntax (unless I am wrong). I can think of tons of examples where you just want the parameter, just like %TITLE% (or even %AUTHOR% or %EDITOR%). I am really enjoying watching DPL develop, and I realize that it is very easy for me to make suggestions without any clue regarding the underlying complexity, so sorry for sounding critical. The above is just an idea about what could be nice. All the best. --Dmb 01:34, 19 September 2007 (CEST)

No comment? --Dmb 21:04, 19 September 2007 (CEST)

I´m afraid of the work ;-). The idea is very good, no doubt. Could you help with implementation? Gero 12:52, 20 September 2007 (CEST)

Sorry to hassle you about it, but I was keen to hear your opinion. I can certainly have a look at the source and let you know what I think. I am glad you like the idea :-D --Dmb 21:10, 20 September 2007 (CEST)

That was a real challenge but I think I can come up with a good solution. The next version will contain the following new feature:

 include  = {template}:parm1:parm2:parm3,#some headline
 table    = (tableclass),(articlelink),colheader1,colheader2,colheader3,chapter title
 tablerow = [[%%|''%%'']],[[Image:%%|200px]],[%% homepage],'''%%'''

You will have access to transcluded contents via "%%". This will also be possible for transcluded paragraphs.

Gero 08:13, 22 September 2007 (CEST)

Re-Open

The parameters format, table, and tablerow seem like they would be redundant. Intuitively, I tried something similar to the following:

|include={A Template}:para1:para2:para3:para4
|format=,¦-\n¦ %% ¦ [[%PAGE%¦%%]] ¦¦ %% ¦¦ %%\n,,

I soon figured out that I couldn't mix the include tokens (%%) with the named tokens in this fashion (or if I can, the method of how to do it eludes me). I know that what I'm trying to accomplish can be done by creating the template A Template Suffix and using:

|include={A Template} Suffix

This, however, has a couple of limitations:

• The name of the template must start with "A Template" which can mislead users as to the purpose of the template, and
• this mechanism limits the named tokens to %PAGE%, %TITLE%, %DATE%, and %USER%.

I propose the following parameters to deprecate the parameters format, include/includepage, table, and tablerow with the syntax:

|headerformat=header
|listitemformat=listitem
|footerformat=footer

where the behavior for listitemformat will be that:

• it will use the special tokens available to the format where applicable.
• it will use a special tokens to specify the include options available for the include parameter:

  Template parameters:

  |listitemformat=blah blah %{A Template}para1% yadda yadda 

  whole articles and individual chapters:

  |listitemformat=%*% blah %##.*omethin.*% blah %#heading1% yadda %#heading2[limit linktext]% yadda %%1[100]%

  and labeled sections:

  |listitemformat=blah %¦sec1% blah %¦sec2% yadda yadda

This would allow users to mix include tokens with reserved tokens with whatever order they desire and specify any template they want or none at all. The example on the Main Page could be rewritten as either:

{| class="wikitable"
|-
! Country || Area || Poplulation || Text || #hits
{{#dpl: category=African Union member states
 |nottitlematch=Sudan
 |mode=userformat
 |addpagecounter=true
 |listitemformat=¦-\n¦ [[%PAGE%]] ¦¦ align=right ¦ %{Infobox Country or territory}area% ¦¦ align=right ¦ %{Infobox Country or territory}population_estimate% ¦¦ <small>%%0[100]%</small> ¦¦ align=right ¦ %COUNT%\n
}}|}

or:

{| class="wikitable"
|-
! Country || Area || Poplulation || Text || #hits
{{#dpl: category=African Union member states
 |nottitlematch=Sudan
 |mode=userformat
 |addpagecounter=true
 |listitemformat=²{Aptly Named Template¦page=%PAGE%¦area=%{Infobox Country or territory}area%¦population=%{Infobox Country or territory}population_estimate%¦text=%%0[100]%¦count=%COUNT%}²
}}|}

Lastly, as a side note, I really dislike using commas as delimiters within parameters when it's likely that they may be in template and/or section names. Although I suppose the issue would still exist with percent sign instead of the comma. —Sledged (talk) 22:40, 26 November 2007 (CET)