From: Lukas Renggli <renggli(a)hotmail.com>
Newsgroups: gmane.comp.lang.smalltalk.squeak.general
Subject: Re: [Q] CMS/Swiki development
Date: Tue, 4 Mar 2003 19:46:37 +0000 (UTC)
Hi Chris,
> I plan to develop a kind of Swiki that is more what I want (nothing
> against swiki, but it's not really the thing I want :-) I think the
> best is with commanche.
I am implementing (with the Software Composition Group at Bern) a new
Smalltalk Wiki implementation right now. There should be a first public
version within a few weeks.
If you want to have a look at some documentation browse to:
http://scgwiki.iam.unibe.ch:8080/SCG/520
Unfortunately there is no public running prototype yet. Alexander will
set-up a server very soon. Most of the needed code is there and working.
We have about 150 Test-Cases that are most running green!
> 1) What would you say is the best starting point (It should
> be faster than swiki)?
> - start from scratch
> - change the existing swiki
We considered using either SWiki or WikiWorks as a base, but did not
like very much those systems from the design point of view. So we
started from scratch.
> - build with seaside
In my opinion Seaside is really the best framework for any kind of web-
application. Unfortunately it is not portable to dialects not supporting
continuations (Avi, correct me if I am wrong). And one of our goals was
to have a Wiki that is easily portable between dialects.
> 2) What do you say about regular expressions. Is the plugin build in
> in the default VM or does the admin has to compile a new VM? Then I
> had to use Streams.
We have a parser building a tree of the content of a page. There are
nodes for any kind of entities like paragraphs, lists, per-formatted
text, internal and external links, smalltalk-code, ...
> - pages sit in a tree (swiki has a graph structure)
Not only the pages are a composite of nodes, also the whole wiki
structure is a tree built of a composite. We do not limit to the model
of SWiki (Shelf, Book and Pages), we may nest at any deep. As internal
links are simply references to another entity, they automatically update
when we move something.
> - userlogin
> - permissions (from user to admin)
> - permissions are bound to a user/page combination and are
> inherited down the tree.
A good security framework is really a problem in the current wiki
implementations. We have a model that is going to give the possibility
to have fine grained security checks: e.g. different permissions to
view,
edit, add, remove, change, upload pages that might be attached to
different groups of users.
I hope that I could give you a brief overview of what I am doing right
now. As soon as things get up and running we are looking for
contributors writing cool extensions!
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi Masashi,
I am currently developing a new Smalltalk Wiki implementation
(http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use
SIXX to store my large tree-structures to xml. It seems to me the
perfect solution, because it can handle circular references and it
dialect independent.
My first attempt was to dump everything out into a XML file using the
following code from your tutorial:
sws := SixxWriteStream newFileNamed: 'root.xml'.
sws nextPut: wikiRootNode.
sws close.
The XML file looks fine, but unfortunately the XML parser is not able
to read that file again. The problem seems to be the huge binary data
(images, pdf) that is stored within ByteArray's.
I think storing binary-data to XML is not a good idea anyway, so I want
them to be put in special external files. The only thing to change - at
least I think so - is my Resource class, that contains this binary
data. So it should only dump the filename of the binary data and not
the data itself. To archive this goal, I wrote something similar to:
Resource>>sixxContentOn: aStream indent: level context: dictionary
| filename |
filename := self generateUniqueFilename.
self dumpToBinaryFile: filename.
super sixxContentOn: aStream ident: level context: dictionary
But how do I prevent SIXX from saving the binary data again, without
hardcoding the other i-vars? How do I archive the loading of the binary
data?
Could you give me some hints?
Thanks a lot for your help
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi,
I'm not feeling very well, so I won't be able to come to the meeting
today. But of course I am reachable by e-mail.
I plan to do some heavy refactorings on the Structure hierarchy and
update the tests today. I don't know how far I will get.
What I plan to do is:
- find a good way to map title to urls
- include property management
- move the template, title, ... i-vars to properties
- create a management interface for properties
BTW, do we want to be able to access properties directly "structure
title" or only with special function calls like "structure propertyAt:
#title"?
Some further goals are (probably not for today):
- attach the security-model
- develop a more generic interface for storage
Sorry for yesterday's e-mail in german: I discussed with Hannes about
SIXX and how easy it is for a dump-out storage. As I already explained
the XML-Parser gets messed-up when parsing very long ByteArrays (used
to store resources). So I think the way to go is to store the
resource-data as external binary files. I don't know yet if this solves
the problems, but at least I hope so.
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Salut Lukas
Lukas Renggli <renggli(a)student.unibe.ch> wrote:
> SIXX hatten wir eigentlich schon ganz zu Beginn des Projektes als
> mögliche Erweiterung im Auge. Gerade letzte Woche habe ich es dann
> integriert, weil ich es für die Präsentation benötigte. Es ist wirklich
> faszinierend, wie einfach und schnell man dieses Framework einbauen und
> nutzen kann.
Schick doch bitte "Masashi Umezawa" <umejava(a)mars.dti.ne.jp>
ein Feedback mit diesem Inhalt. Er leistet eine gute Arbeit,
kriegt aber nicht so viel Echo von der Liste.
> Wir werden weiterhin mit SIXX arbeiten, die Bilder und andere binäre
> Daten müssen aber in separaten Dateien abgelegt werden. Das ist zwar
> auch vom Platzbedarf her gesehen vorteilhaft,
Ist vom Nutzer / Betreiber-Standpunkt aus sehr gut!
aber man kommt nicht mehr
> mit nur 3 Zeilen Code aus.
Ja, leider! Hoffentlich nicht allzuviel Mehrarbeit.
Liebe Grüsse
Hannes
Hallo Hannes,
> Ich denke eine relativ einfache Addition könnte den "Verkaufswert"
> für euer Wiki massiv erhöhen. Wenn ihr als Rendering-Option
> den Export nach XML (SIXX * in Squeakmap) einbaut.
>
> Es dürfte sich einfach darum handeln SIXX zu laden
> und einige wenige Zeilen am richtigen Ort einzubauen
> und ihr habt euren Export nach XML.
SIXX hatten wir eigentlich schon ganz zu Beginn des Projektes als
mögliche Erweiterung im Auge. Gerade letzte Woche habe ich es dann
integriert, weil ich es für die Präsentation benötigte. Es ist wirklich
faszinierend, wie einfach und schnell man dieses Framework einbauen und
nutzen kann.
Leider scheint es aber Probleme beim Laden der XML-Daten zu geben
(daran ist meine Präsentation fast gescheitert). Besonders bei den
Byte-Arrays, welche ich verwende um die binären Daten der Bilder
abzulegen, dreht der XML-Parser durch und es treten sehr komische
Fehler auf.
Wir werden weiterhin mit SIXX arbeiten, die Bilder und andere binäre
Daten müssen aber in separaten Dateien abgelegt werden. Das ist zwar
auch vom Platzbedarf her gesehen vorteilhaft, aber man kommt nicht mehr
mit nur 3 Zeilen Code aus.
> Das würde sicher auch einen guten CT-Artikel abgeben.
Ja, das denke ich mir auch. Es gab ja vor kurzem einen Vergleich von
verschiedenen Wiki-Implementationen im CT, leider wurde darin aber
nicht auf die Smalltalk-Varianten eingegangen. Aber es ist dennoch gut
zu wissen was die Konkurrenz kann
> Dies also ein Feedback auf die interessante Demo vom letzten
> Samstag
Vielen Dank und liebe Grüsse
Lukas
On Montag, Februar 17, 2003, at 08:46 Uhr, Hannes Hirzel wrote:
> Hallo Lukas
>
> Obwohl ich vielleicht etwas desinteressiert deiner Präsentation gefolgt
> bin, muss ich
> im nachhinein sagen, dass mich das was ihr macht sehr interessiert.
>
> Ich bin auch gerne bereit ggfs. ein Alphaversion zu testen....
>
> Der Gedanke im Smalltalk-Image drin ein komplette Objektnetz von
> Dokumenten zu haben, die sich auf verschiedene Weise rendern
> können ist wirklich faszinierend.
>
> Ich denke eine relativ einfache Addition könnte den "Verkaufswert"
> für euer Wiki massiv erhöhen. Wenn ihr als Rendering-Option
> den Export nach XML (SIXX * in Squeakmap) einbaut.
>
> Es dürfte sich einfach darum handeln SIXX zu laden
> und einige wenige Zeilen am richtigen Ort einzubauen
> und ihr habt euren Export nach XML.
>
> Damit habt ihr dann sogar ein Autorensystem (Wiki-Syntax)
> das XML produziert (ein Content Managemet System).
>
> Das würde sicher auch einen guten CT-Artikel abgeben.
>
> Dies also ein Feedback auf die interessante Demo vom letzten
> Samstag
>
> Grüsse und weiterhin 'happy squeaking'
>
>
> Hannes Hirzel
>
> --------------------------------------------------------------
> * Mail zu SIXX von heute
>> Date: Tue, 18 Feb 2003 00:55:17 +0900
>> From: "Masashi Umezawa" <umejava(a)mars.dti.ne.jp>
>> Subject: Re: port of prevayler
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev(a)lists.squeakfoundation.org>
>> reply-to: The general-purpose Squeak developers list
>> <squeak-dev(a)lists.squeakfoundation.org>
>>
>> Hi,
>>
>>> Yes, much better. :-) We have one good language (Smalltalk) why not
>>> use
>>> it? All this focus on XML (in the IT industry over all that is) is
>>> really tiresome.
>>
>> Tiresome, indeed. But I think SIXX has some advantages for serious,
>> robust
>> systems.
>>
>> - It automatically resolves circular or shared references.
>> (In "do it" approach, you have to write it on your own).
>>
>> - It is safe.
>> ("Do it" could be a security hall. You can insert dangerous
>> expressions).
>>
>> - It is portable.
>> (SIXX has been ported to 3 Smalltalks. It can be converted to other
>> data
>> structures by processing parsed dom tree).
>>
>> So I think it is oversimplified to say "much better".
>>
>> ---
>> [:masashi | ^umezawa]
--
Lukas Renggli
http://renggli.freezope.org
Hi
What I would like to be able to say is for a given page that it get
automatically time-stamped with the lats update.
Stef
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes
Hi all,
I think that tuesday we should look at a simple problem of integration
and see how
the extended actions works or not.
I was thinking that we will need a kind of configuration object that
represents
which kind of extension are required.
Stef
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes