Talk:Threaded discussions with NavFrames

Is there a better demo page than Wikiversity:Threaded discussions with NavFrames with subst/20070522105803? Most of the table of contents items do nothing when I click on them. I wonder if there is any way to have a table of contents that could open the navboxes. --JWSchmidt 00:38, 26 May 2007 (UTC)

• Indeed. I do not understand the javascript, and so I do not know if we can fix it. One possible solution would be to add a button for opening and closing all NavFrames at once; or we may just use another class whose default would be open. (Is there such a class?) On meta, with my monobooks, the frames are always open (and they don't close).
• In short, question to javascript experts: Is it possible to write the java script so that one click of the "expand" actually open all the subframes?

--Hillgentleman|Talk 04:57, 26 May 2007 (UTC)

After looking at MediaWiki:Common.js I think is should be possible to make an "expand all" functionality. I think it would be easy to make an "expand all/collapse all" button that could be placed on pages. In this situation with the table of contents, it would be nice if a click on a link in the table of contents would expand just the collapsed box with the desired page section. I think there might be a possibility for a solution to this that would not involve an "expand all/collapse all" button.It seems like you could write a routine that would check to see if a user's click is on a failing link to a page section inside a collapsed box. If so, the box would be expanded and the user's view of the page would scroll to that section. --JWSchmidt 15:10, 26 May 2007 (UTC)

Is this an alternative to LiquidThreads? I'm no Javascript expert, but I can fiddle with it if that is the track this is on (or if someone explains what this is supposed to be. :) Historybuff 18:10, 29 May 2007 (UTC)

• Historybuff, This is a model of a threaded discussion system. It is not related to the liquid thread program m:LiquidThreads. Our model is flexible enough to capture most features of liquidthread (perhaps sometimes with the aids of simple robots such as those by Michael Billington for Colloquium feeds). And it is purely wiki. I first wrote it to see how far the MediaWiki syntax could take us (i.e. I did it for the sake of doing it). JWSchmidt also thought about it before. It can be improved further, and there is at least one alternative. I am using it on my talk page. Anybody may choose to try her hands on it.
• Expanding a NavFrame from the TOC is a useful feature in general, and not just for this learning project.Hillgentleman|Talk 18:23, 29 May 2007 (UTC)

Additional ParserFunctions

I'm wondering if the #time: parser function could be used to "break out" useful values from the {{REVISIONTIMESTAMP}} to build a subpage structure. In my user space, I've started a Weekly journaling system that works from a crude {{queue}} to generate a daily page with the format User:CQ/2007/W21/3:

Weekly Schema:

FULLPAGENAME

/2007 current YEAR from #time:Y

/W21 current ISO 8601 WEEK number (1-53) from #time:"W"W

/N current ISO 8601 DAY of the week (1-7) from #time:N

/H (optional) current HOUR of the day (00-23) from #time:H

etc... using #time:i, #time:s or even #time:U

The subpages automatically link up as they go (at least in the User: namespace). This schema seems to be working OK for keeping a personal or group journal, but I don't know if or how it could help with threaded discussions. I just think it's some cool functionality worth mentioning. CQ 20:45, 30 May 2007 (UTC)

CQ, Do you mean 01 Apr 2018 20:18? Hillgentleman|Talk 21:22, 30 May 2007 (UTC)

The actual date (of the example) was 23 May 2007 which can also be identified as Year:2007 Week:21 Day:3 or ISO 8601-styled 2007/W21/3 (Wednesday [day 3] of the 21st week of 2007). Note that If higher-level pages exist, they are automatically linked from lower-level pages.

Today's date yielded by {{#time:d M Y|{{REVISIONTIMESTAMP}}}} or 01 Apr 2018 is more human readable, but as a subpage structure, one may need to go in a "big endien" style from largest reference (2007) to smallest (the current day) with each reference being "unique" in the subpage structure. For hourly, minute-by-minute or even second-by-second tracking, it might be desirable to do that within a "daily" subpage.

If the group would rather do things in months (rather than weeks) and then days, they can use something like 2007/05/23 to format a subpage tree. In that case, a "queue" (to produce a link for "today") would look like {{#time:Y/m/d|{{REVISIONTIMESTAMP}}}} yielding 2018/04/01. That way you get a "folder-looking" structure that can expand, collapse, append and navigate in logical ways. Using numeric identifiers for Months or Weeks helps when calculating time spans and concurrency (last year, next month, etc.), but daynames and monthnames can be used too.

Sorry if this is unclear or irrelevant. I'm not good at explaining things. CQ 23:07, 30 May 2007 (UTC)

Oh yeah.. The point is that you can break any one or group of values out of {{REVISIONTIMESTAMP}} using the parser function #time: and its parameters to create subpages and links to them "on the fly". -- CQ 23:17, 30 May 2007 (UTC)