[squeak-dev] Proposing class Category README or HOWTO for easy access to documentation within the system

Chris Cunnington brasspen at gmail.com
Thu Jun 12 22:39:50 UTC 2014


On Jun 12, 2014, at 5:25 PM, tim Rowledge <tim at rowledge.org> wrote:

> We already have a fairly decent Help system available; see the help item in the top docking bar menus. What we lack is content for that help system, and a clear organisation of it; consider the several workspaces, the Terse Guide, the Help Browser that also includes the terse guide. I’d suspect that having a nice link to available help info from the Browser might encourage more use of it.
> 
> The tool is decent and would be better with simpler organisation, but the real missing part is content. The problem is that writing good help & tutorial content is hard work. Take a look on the swiki to see how several groups and individuals have tried to build tutorials and lost steam after a while. I’ve been trying to clean up and update some of it but it takes a lot of thought and a startling amount of time.
> 
> On the plus side, a good bit of help/tutorial on a single, narrow area is still a good bit of help. It’s not you have to write a guide to the entire system in one go. Writing help info is a very good exercise when you are learning about a new bit of the system; nothing helps you organise your thoughts and test your understanding like trying to provide a clear explanation for others

Help system is a delivery system while wiki.squeak.org has lots of good content. A cool thing to do here is to have the Help system serve the wiki content. In the same way that SqueakMap uses a web interface for new content and then serves that content in the image with a GUI widget use Help system as a vector for the consumption of wiki pages. 

I'm in the process of exploring how the XML pages used by Swiki as on-disk persistence can be converted into TinyWiki objects, into objects that can be stored in an SSRepository file and served by a hacked SS2. I have a workflow [1], but I need to make it work and then automate it. 

I think that once I have the wiki pages saved as an SSRepository file, then anybody could download it, like a SqueakMap map file, and consume it with Help system. 

Chris 



> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Puts a finger in his ear so the draft through his head isn't annoying.
> 
> 
> 

[1] 

NuSwikiPage 
	name: 'Intro to 1.5'
	text: a String pulled from an XML file 

1. Replace name spaces with hyphens (i.e. Intro-To-1.5 ) to be used later as the URI token like /squeaksource/Traits, /squeaksource/MineSqeeper, /squeaksource/Intro-To-1.5
2. Use the correct Swiki action to convert the page numbers (i.e. *1*) in the NuSwikiPage>>text into proper names for the links (i.e. *Intro to 1.5* ) 
3. Make a dictionary where the keys are the name and the values the complete wiki format string. 
4. Modify TWParser in TWWiki so that it creates HTML links instead of what it already does. 
5. Feed the value, the wiki format string, into the TWParser and get a TWPage. 
6. Push the keys and values into SSProject instances:

SSProject 
	id: 'Intro-To-1.5'
	wiki: a TWPage

7. Put the SSProject into SSRepository 
8. Serve with Ohana ( a hacked SS2) 

The end result is that you modify SS2 ( with a project called Ohana) so that it serves Swiki pages as TWWiki pages. You've seen this before, because every single SS2 project has it's own wiki.  
That means a Swiki NuSwikiPage is converted to a TWWiki object, which is easily rendered with Seaside. And it opens to be edited just like any project wiki in SS2. Then move all 6100 Swiki pages to box4 as a single SSRepository file. 

The point is that with all this conversion of godawful XML files into TinyWiki objects, I can create a separate conversion process and feed them to Help system. There's you're content. 
I like this idea. I've already done the worst parts. I'll explore it. 




More information about the Squeak-dev mailing list