W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2013

Re: JS page templates and topics

From: Eliezer Bernart <eliezer.bernart@gmail.com>
Date: Sun, 8 Dec 2013 00:57:01 -0200
Message-ID: <CAAECTTSjbyk4iAQTuqCjVbDuiX-4UytnKhPA6qUXXP3vSzEF0w@mail.gmail.com>
To: Julee Burdekin <jburdeki@adobe.com>
Cc: Max Polk <maxpolk@gmail.com>, Webplatform List <public-webplatform@w3.org>
Hie Max,

+1 to everything. I just have a question...

Once we start with a non-multi-layered approach and we want to change to a
multi-layered, how difficult or painful it will be the process to do this

Thanks, you made some points more clear to me!



On Sat, Dec 7, 2013 at 6:08 PM, Julee Burdekin <jburdeki@adobe.com> wrote:

>  Thanks, Max: I think that's where we are at. But I think we should keep
> templates work in the templates project. This is because it is a unique
> skill and the person who is doing it can then have one location where the
> bugs are. You can relate bugs to each other at project.webplatform.org.
> J
> Sent from my "smart" phone... go figure...
> -------- Original message --------
> From: Max Polk
> Date:12/07/2013 10:56 AM (GMT-08:00)
> To: Webplatform List
> Subject: JS page templates and topics
> Concerning JS page templates, I'm happy to see Eliezer is tackling the
> outstanding flags issue:
> http://lists.w3.org/Archives/Public/public-webplatform/2013Dec/0035.html
> Eliezer and all, can I begin talking about the topics and topic
> clusters?  It feels like a good top-level issue to tackle relating to JS
> templates.  With multiple people working the same thing we don't want
> overlap.  Assuming I can move forward, here are a few notes.
> The overall approach to topics and topic clusters is nicely described:
>      http://is.gd/kl5LIu
> For this email let's stick with just topic.  Let us glance at "CSS" and
> "CSS-Regions" topics, the first being for the 'basic meta data' use case
> for lots of pages, and the second being for 'API Basic Listing
> Configuration Query' use case for multi-layered page hierarchy.
> For the multi-layer, the "CSS-Regions" is used inside pages of template
> type {{API_Object}}, so a search can be formed to find it automatically,
> such as:
> {{API_Listing|Query=[[Category:CSS-Regions]][[Category:API_Objects]] ...
> For multi-layer, the template type is highly aligned with topic.
> We could go with non-multi-layer, and decide the topic is only
> "JavaScript language", then have a single template for all pages in it.
> It's simple, it's reasonable, and it's fast to get up and running.
> At the moment we have two legacy template types for JavaScript pages:
> "JavaScript Operator" and "JavaScript Statement".  See the new page
> selector to glance at them:
>      http://docs.webplatform.org/wiki/WPD:New_Page
> We could simplify and stick with just one template and one topic. So
> this is the very first decision to make, what *kinds* of JavaScript
> pages will there, relevant to the kind of template each will use.  And
> do we want the simple approach of non-multi-layered.
> What will guide the answering of this crucial question is the notion of
> what general structure the various JS pages will have. At the moment,
> there is generally only one structure, so the simple non-multi-layered
> approach sounds good at first thought.
> Topics currently:
> http://docs.webplatform.org/wiki/Property:Topics
> The above contains "JavaScript".  Many pages are tagged with it:
> http://docs.webplatform.org/wiki/Category:JavaScript
> We could start a new "JavaScript language" topic and I could add this to
> all pages being uploaded:
>      {{Topics|JavaScript language}}
> By adding that Topics template it creates the category "JavaScript
> language".  We have to, by convention, edit that category page and make
> it part of the "Topics" category, the needed manual step for new topics
> as documented at (http://docs.webplatform.org/wiki/WPD:Topics).
> We will defer topic clusters, for later:
> http://docs.webplatform.org/wiki/Property:Topic_Cluster
Received on Sunday, 8 December 2013 02:57:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:56 UTC