APL Wiki|
Size: 2685
Comment:
|
← Revision 13 as of 2009-06-16 20:36:55 ⇥
Size: 2476
Comment: Typo correction
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Providing useful information to APL programmers can be done in a number of ways. In a Wiki, there is no way to enforce people to follow particular conventions. You might think about this as an invitation to create chaos. A very different view would be that this way good things will defat the less good ones sooner or later. | Providing useful information to APL programmers can of course be done in a number of ways. In a Wiki, there is no way to force people to follow particular conventions. You might think about this as an invitation to create chaos. A very different view would be that this way good things will defat the less good ones sooner or later. |
| Line 3: | Line 3: |
| == How to Provide Code == | However, here are some hints and suggestions you might find useful. == How to provide code == |
| Line 10: | Line 12: |
| If you have created a particular page, please put a "Author: FirstnameLastname" at the end of the article if you are willing to keep an eye on the page. Write it like KaiJaeger, because this let the Wiki link automatically to your "homepage". This is another good reason to create such a homepage. == Linking == === Overview === Wikis do *not* contain highly sophisticated structured pages which are all anchored into a menu. This makes not much sense because thi is very hard to maintain, at least in a large Wiki. Two different methods are available in MoinMoin-driven Wikis: === Sub Pages === Use the "!Mainpage/Subpage" mechanism when appropriate. That makes navigation for the user much easier. For example, if you want to add a "!MySpecialPage" to the !DotNotSamples page, specify "!DotNotSamples page/MySpecialPage" as page name. Consult the help pages for more information. |
If you have created a particular page, please put a "Author: !FirstnameLastname" at the end of the article if you are willing to keep an eye on the page. Write it like KaiJaeger because this let the Wiki link automatically to your "homepage". This is another good reason to create such a homepage. |
| Line 26: | Line 16: |
| Adding a string "!CategorySomething" offer a link to a so-called category page. When such a page is created, a MoinMoin macro can be inserted to produce dynamically a list of pages which also contains such a link. That is very usefule because new pages are automatically added to the list as soon as the become available. | Adding a string "!CategorySomething" offer a link to a so-called category page. When such a page is created, a !MoinMoin macro can be inserted to produce dynamically a list of pages which also contains such a link. This is very useful because new pages are automatically added to the list as soon as they become available. |
| Line 28: | Line 18: |
| === Conclusion === | You might connect a particular page to several categories if this is appropriate. This makes it easier for others to find the page. For details see WhyUsingCategories |
| Line 30: | Line 20: |
| For top-level links, using sub pages is recommended. For all other pages, make sure that they belong to at least one category. However, you may also use the sub page mechanism. | === Sub pages === |
| Line 32: | Line 22: |
| == .NET pathes == | Use the `"Mainpage/Subpage"` mechanism when appropriate. An example is the three-goats-problem: On one page, the task is defined, on a second the solution explained. Both pages are kept under "3goats". The pages themselves are named "task" and "solutions". So there is a page "3goats/Task" and a page "3goats/Solution". |
| Line 34: | Line 24: |
| Address .NET methods/classes/enumerations/interfaces always fully. This makes it not only easier to understand the code, it makes also much easier to find related articles. For example, if you use the ⎕USING mechanism, you can call the method "!ShowHelp" from System.Windows.Forms.Help by adressing it as "!ShowHelp". Surely there are plenty of other methods with exactly the same name! So it is more appropriate to search for System.Windows.Forms.Help.!ShowHelp if your are looking for an example how to use this .NET method. | == .NET paths == Address .NET methods/classes/enumerations/interfaces always fully. This makes it not only easier to understand the code, it makes it also much easier to find related articles. For example, if you use the ⎕USING mechanism, you can call the method "!ShowHelp" from System.Windows.Forms.Help by addressing it as "!ShowHelp". Surely there are plenty of other methods with exactly the same name! So it is more appropriate to search for System.Windows.Forms.Help.!ShowHelp if your are looking for an example how to use this .NET method. |
Providing useful information to APL programmers can of course be done in a number of ways. In a Wiki, there is no way to force people to follow particular conventions. You might think about this as an invitation to create chaos. A very different view would be that this way good things will defat the less good ones sooner or later.
However, here are some hints and suggestions you might find useful.
How to provide code
At the time being (2006-12-24) examples are provided as code block with lots of comments. This means that one can create the code in an APL workspace which can be saved for later use, like maintaining or enhancing.
On the other side you might find all the comment lines annoying the code is coming with.
Author
If you have created a particular page, please put a "Author: FirstnameLastname" at the end of the article if you are willing to keep an eye on the page. Write it like KaiJaeger because this let the Wiki link automatically to your "homepage". This is another good reason to create such a homepage.
Categories
Adding a string "CategorySomething" offer a link to a so-called category page. When such a page is created, a MoinMoin macro can be inserted to produce dynamically a list of pages which also contains such a link. This is very useful because new pages are automatically added to the list as soon as they become available.
You might connect a particular page to several categories if this is appropriate. This makes it easier for others to find the page. For details see WhyUsingCategories
Sub pages
Use the "Mainpage/Subpage" mechanism when appropriate. An example is the three-goats-problem: On one page, the task is defined, on a second the solution explained. Both pages are kept under "3goats". The pages themselves are named "task" and "solutions". So there is a page "3goats/Task" and a page "3goats/Solution".
.NET paths
Address .NET methods/classes/enumerations/interfaces always fully. This makes it not only easier to understand the code, it makes it also much easier to find related articles. For example, if you use the ⎕USING mechanism, you can call the method "ShowHelp" from System.Windows.Forms.Help by addressing it as "ShowHelp". Surely there are plenty of other methods with exactly the same name! So it is more appropriate to search for System.Windows.Forms.Help.ShowHelp if your are looking for an example how to use this .NET method.