AW: [templates] Listing pages

Heya,

 

I can take a look at the weekend, IIRC the things to do were:

-          Move the core stuff from Template:API_Listing to
Template:Concept_Listing

-          Template:API_Listing now only sets the category

-          In Form:API_Listing the "Basic Listing Configuration" is replaced
by a call to Template:Concept_Listing_Form_Section

-          You didn't mention this: is {{{for template|API_Listing}}} in
Form:API_Listing replaced with {{{for template|Concept_Listing}}}?

o   If so, where is Template:API_Listing called to set the category?

o   If not so, where is Template:Concept_Listing called to generate the
table?

 

So as it seems this can either be used as {{{for
template|Concept_listing}}}{{Concept_Listing_Form_Section}}{{{end
template}}} in Forms or directly via
{{Concept_Listing|Query={{{Query|}}}|Use_page_title={{{Use_page_title|}}}.

 

You can implement this yourself, if you want - as a learning exercise, like
you said. :)

 

I'm at work, so no time to check everything, I might have missed something.

 

-fro

 

Von: Scott Rowe [mailto:scottrowe@google.com] 
Gesendet: Freitag, 28. Dezember 2012 01:07
An: Alex Komoroske
Cc: frozenice; public-webplatform@w3.org
Betreff: Re: [templates] Listing pages

 

Hi frozenice,

 

Alex and I were planning on implementing all this before the holiday break,
but we got jammed. It would be nice to do this while the site is relatively
quiet. Would you like to make these changes this week or next while the
rabble rousers are out of town?

 

+Scott

 

 

On Tue, Dec 18, 2012 at 4:48 PM, Alex Komoroske <komoroske@google.com>
wrote:

 

On Wed, Dec 12, 2012 at 1:27 PM, frozenice <frozenice@frozenice.de> wrote:

Sounds good! Some remarks inline... :)



On 11.12.2012 23:55, Scott Rowe wrote:

First, we pull the guts out of the Template:API_Listing and make a new
Template:Concept_Listing:

{{#if:{{{Query|}}}|{{#ask:{{{Query|}}}|?Page_Title|?Summary|link=none|format
=template|template=Summary_Table_Body|introtemplate=Summary_Table_Header{{#i
feq:{{{Use_page_title|}}}|Yes|_Pages|}}|outrotemplate=Summary_Table_Footer|s
earchlabel=See
more pages...}}|}}
{{#ifeq:{{{List_all_subpages|}}}|Yes|
==Subpages==
{{Special:PrefixIndex/{{PAGENAME}}/}}|}}

Now, I forget, does the following piece go in the above somewhere?

{{Concept_Listing|Query={{{Query|}}}|Use_page_title={{{Use_page_title|}}}

 

That piece (which is missing }} at the end btw) calls the above one. It sits
in Form:API_Listing disguised as:
{{{for template|API_Listing}}}



> ! Use page title (instead of API_Name):
> | <nowiki>{{{field|Use_page_title|input type=checkbox}}}</nowiki>

As this is going to be included everywhere, should we leave "API Name" as
the default value or change it?
The label would have to be adjusted if the default value is changed and we
propably would need to fix up articles.
Note that it's currently not possible to pass an arbitrary title to the
table header template, as I outlined earlier:
http://lists.w3.org/Archives/Public/public-webplatform/2012Dec/0157.html

Or, we could have more than two values if we change my #ifeq into a #switch
and provide a select-box instead of a checkbox
in the form, but that would also require more table header templates (with
different suffixes, like _Pages).

 

Whew, that could get complicated quickly.  Do we know of use cases for the
template today that would require more than the two options? If we don't,
I'd prefer to stay with the checkbox.

We could reduce redundant code if we put in another nested template, but as
the summary table header is only 3 lines
of wiki code, that shouldn't be necessary.
The select-box would be fueled by a property
(Property:Concept_Listing_Main_Column_Titles or such :D).
We could assume "API Name" if nothing is selected yet, so we don't need to
fix up articles.

That's a great idea in general.



> We replace the above with a call to the Concept_Listing form template
>
> {{{for template|API_listing}}
> {{Concept_Listing_Form_Section}}

Why did you move {{{end template}}} into the form section template? It's the
counterpart of {{for template|}},
so those two should be on the same level (at least for readability, Semantic
Forms might handle it either way).