> The whole reason I did Gardner in the first place was that SmallWiki
> came with Yet Another Web Serving Framework, and my feeling is that
> we've got enough of that in Squeak. So I picked the good stuff (the
> parser etcetera) and forgot about the rest.
the reason that SmallWiki is not using Seaside, isn't because I don't
like Seaside (I'm having a lot of fun building professional
web-applications with Seaside), but because I wanted to be dialect
independent. E.g. the SmallWiki port of John Brant to .NET and
#Smalltalk wouldn't have been possible if I based on a framework using
> Also, SmallWiki, even though it is called 'Wiki', has higher
> - AFAIK it aims more at Zope. I have installed SmallWiki last summer
> under VW at Soops, and although we used it (mostly by default -
> WikiWorks sucks and there's nothing else) we didn't really like this
> File/Folder stuff in a Wiki.
as far as I know you are still using a very old version of SmallWiki at
Soops. At that time I just introduced the new folder concept and it had
not been integrated into the UI properly yet. With the latest version
most beginners don't even realize that they are working within folders,
as the flow of actions (e.g. to upload a resource or create a new page)
has been improved to mach more the way SWiki did. Of course the experts
still have the full power to organized their data in a tree of folders,
if they want.
Seaside mailing list
> wir (die ese-staff) haben ein kleines problemchen mit dem smallwiki:
das sieht wirklich chaotisch aus. Ich weiss auch nicht wie man das mit
einem Skript lösen könnte, schliesslich musst du ja selber wissen wo
welche Seite hineinkommt.
David Vogel arbeitet an einem Tool, um die Inhalte von Ordnern zu
kopieren und zu verschieben, das könnte hier weiterhelfen.
> 2) La deuxième question est encore assez générale : Lorsque
> l'utilisateur tape dans la zone textarea, on aimerait bien implémenter
> une analyse de la syntaxe dynamique. Or il existe un attribut de
> textarea qui est onKeyPress. Et demande comme paramètre une commande
> script. Comment utiliser cela dans smalltalk? Et que doit-on mettre
> dans la commande script pour pouvoir exécuter une méthode de la classe
> même? (Par exemple, si on tape sur une touche, on appelle la méthode
> MiseAjourTextarea de la classe).
doing dynamic things like the described one is very difficult using the
web, because the HTTP protocol only supports a one-way communication:
the client has to request a page.
and allows sometimes to go around those limitiations. One could create
a textarea using the following the shape of
<textarea OnKeyPress="submit();" ...
This would cause the textarea to be submitted every time the user hits
a key. Unfortuantely this won't be useable, because a new page is then
loaded into the browser and the current cursor position, the selection
in the text-box, etc. are lost. It could be possible to write some more
parts of the page), but I don't suggest to do so as this won't work on
different browsers and is probably too slow anyway.
more than it helps ... but this is just my personal opinion.
I can only give the following solutions:
* Add a preview-button to your text-area to allow the user to see the
actual output from time-to-time.
* Have a look at XUL project (part of Mozilla) that provides some
extensions to the HTTP protocol to allow creating better UIs, in fact
the whole Mozilla GUI is built using this framework. As a drawback this
run on the Mozilla browser; but at least the possiblities look
> the newer parser is pretty trivial work). It'll probably be easy to
> migrate a wiki back and forth between Gardner and SmallWiki since I
> think they use the same DOM in addition to the parser.
Exactly, SmallWiki is providing basically the same protocol for HTML
generation. However there are two things:
- Expressions like "html attributes align: #middle" are not supported
yet. You still have to do it the old-fashioned way "html attributeAt:
#align put: #middle". If someone wants that, it could be changed
- The callback-mechanism of SmallWiki is somehow different, as there is
no state in the components: therefor I have to pass into the
block/message some more information than just the current value.
Basically you register your callback either using a symbol or a block:
(1) (2) (3)
[ :action :value :mime | self foo ...
(1) (2) (3) (4)
(1) points to the action where the callback is evaluated
(2) points to the value of the (input-)callback (this is what you get
(3) points to the mime-code of the (input-)callback
(4) points to the action where the callback had been defined
If your SmallWiki block/message does not take all the arguments, they
are simply not given when evaluating.
I put an additional question on the FAQ
How do I upload a style-sheet to my root folder as a resource?
I think I figured out the answer and wrote it on
However it doesn't work.
I did change 'Template', link 'Stylesheet' to
What am I missing?
P.S. I work with the Squeak version I got four days ago from SM.
P.S. 2 As a workaround I copy the whole style sheet at the moment into
the template box. It works fine but I do not feel at ease doing so.
I created a page put resources in it then, I changed the title of the
page and in the page referring to it, the references were not found
I got resource, page, folder instaed of the linkn to the page. I
reedited the previous page to have the previous title and everything
worked well. I will show you because I can reproduce it.
I did some cleaning today:
- I've updated the documentation on
http://kilana.unibe.ch:9090/SmallWiki and added a few tests.
- I removed the restriction to evaluate a call-back only once, because
this caused some confusion in certain cases. I observed several people
editing and viewing pages using the save-button and the back-button of
the browser: the problem there is that the save-callback is considered
to be evaluated several times, so this should work in a more convenient
- Structure>>references will return a set with all structures in the
wiki pointing to the receiver. Structure>>referencesStartingAt: will
do the same but the search will start at the given parameter. Try out
this feature by adding the component References to your wiki.
- When renaming a wiki-pages all references pointing to that page are
now correctly updated. However there is still a problem when a the
renamed structure appears in the middle of a path (only possible for
folders), in that case nothing is done automatically yet.
- I've introduced VisitorPluggable as a subclass of Visitor to make the
use of visitors more easily. This allowed to get rid of a few other
visitors. VisitorPluggable has the constructor #block:start: to get
everything started. There are currently two subclasses called
VisitorLinkInternal and VisitorStructure that both just evaluate the
block for the appropriate wiki-items. The re-factored hierarchy looks
now like seen on:
As an example the two changes mentioned above are now implemented using
this kind of visitor:
| collection |
collection := Set new.
block: [ :link :structure |
self == link target
ifTrue: [ collection add: structure ] ]
block: [ :link | self == link target ifTrue: [ "fix link ..." ]
start: self root.
- The alt-attribute is now rendered correctly for images.
That's it for the moment (other things to do),
I installed SmallWiki in Squeak today--I'm impressed!
Here are a couple of potential porting issues:
I found a call to OrderedCollection>>replaceAtIndex: that is #replaceAt:
in Squeak. The changeset showing the change is attached.
Also, I ran SmallLint methods sent but not implemented and found:
SWDocumentComposite>>postCopy sends super postCopy but no superclasses
of SWDocumentComposite implement it.
SWCode>>internalEvaluate:on:with: contains the following expression
which is not implemented:
ifFail: [ nil ]
handler: SilentCompilerErrorHandler new
SWPropertyManager>>postCopy also calls super postCopy which is not
SWSIXXStorage>>directoryTime sends hour to TimeStamp now, but TimeStamp
doesn't implement hour.
SWStructure>>postCopy sends super postCopy, which is not implemented.
SWServer>>emitContext:on: sends aContext localScope, which is not
SWBasicRole>>postCopy sends super postCopy which is not implemented.
There is a class SWDocumentComposit, possibly a typo from
SWDocumentComposite, but has some differences in methods. Also it's
postCopy sends super postCopy, which is not implemented.
SWText>>postCopy sends super postCopy, which is not implemented.