> Thats the same in my image, there is really a message ip and ip: . so
> the problem may have other reasons ?
StORE is sometimes a mystery to me, I already experienced quite a lot
of strange bugs while developing SmallWiki. One more thing that you
could check, is if SmallWiki.SwazooServer is a subclass of
SmallWiki.Server, else I do not understand why it cannot find the
message #ip:
> Of course, I will also load the newest version (must I remove the old
> package before doing this ?)
Usually it should work without unloading.
> Perhaps we could talk a little bit about Smallwiki on Smalltalk Party
> in november.......
Yep, I will be there and could also present some new features and
decisions made recently. Until then the Version 1.0 should be ok ;)
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi,
> perhaps you can help me: I've loaded SmallWiki from Public Store
> (V0.9.18 for SmallWiki and V.5 for Swazzo), and if I try
>
> [...]
>
> I'm using vw-nc release 7.
We are using vw-nc 7.1 for development, but if you load the latest
version of Swazoo and the other prerequisites from Cincom StORE it
should just work fine.
> 'Unhandled exception: Message not understood: #ip:'
> Swazoo.HTTPServer(Object)>>doesNotUnderstand:
> SmallWiki.SwazooServer>>start
> SmallWiki.SwazooServer class(SmallWiki.Server class)>>startOn:host:ip:
> SmallWiki.SwazooServer class(SmallWiki.Server class)>>startOn:
> ...
That is strange, because in my image there is the message #ip:
implemented in SmallWiki.Server, the superclass of
SmallWiki.SwazooServer. You could try to reload the latest version of
SmallWiki from the Cincom StORE, to see if that help. Well, this is the
only suggestion I can think of at the moment ...
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hello
I do not know if you share my feeling, but perhaps the administrator of this list can set the reply address to smallwiki instead of the sender of the mail.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hallo,
i started working with smallwiki!
I use pages and internal links for viewing my textest..
I have some picture that must be includes in my text pages.
How can i do this in Smallwiki?
I can not find some area where i can upload pictures, or other files?
TIA Nic
``-''
( @ @ )
------ooooO--(_)--Ooooo------
Sorry in french but this is related to search facility and indexing
> Comme source d'inspiration, il faudrait regarder du côté de Lucène, un
> moteur d'indexation et recherche écrit en Java
> (http://jakarta.apache.org/lucene/)
> ainsi que de sa version Python Lupy (http://www.divmod.org/Lupy/). La
> version Python permet de lire
> notamment les index créés par la version Java.
>
> On doit pouvoir faire aussi bien en Smalltalk et avoir une certaine
> compatibilité avec Lucène ! Il n'y a pas un étudiant
> sur la liste qui cherche un projet ? ;-) Je peux essayer de proposer
> cela
> chez moi comme projet de maitrise également.
Hi Michele,
> PS. Let's give it a try: on the 'Changes' page of the Swiki I would
> like to see who made the changes by listing either an IP address and
> some machine info (Swiki does it like that) or (hmm.. ;-) even better:
> The 'Role' of the Person editing the page (was it the creator, a
> maintainer, a (supposedly) read-only person, or some stranger). The
> information should be displayed in a nice table (perhaps on a
> on-the-fly generated page) when I inspect the changes. (This could be
> pushed even further in case a SmallWiki is highly used: an automatic
> 'hacker' detector which correlates some information (for example
> consistent uploads etc.) and triggers automatic defense mechanisms
> like making the Swiki unreadable.. ;-\)
the problem here is that this information is not collected right now,
but of course one could add it easily. I am usually adding that kind of
things when there is the need, but right now I am on holiday, therefor
you have to implement it for yourself or wait a few weeks.
> PPS. You have to protect the top-page (which is the admin page) of the
> current Smallwiki on kilana by means of a password or something like
> that.
The top-page (it is actually a folder) is no different to other pages.
If one wants to simulate the SWiki behavior it is possible to protect
it, of course, but I try to keep everything as open as possible and
just protect the things that might harm your system per default.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
I was looking at adding a file based storage mechanism. I want it to save
each change to a file whenever it happens, instead of waiting some interval
and then saving all pages. Anyway, I've added my new class, but it appears
that the #changed: message is getting the wrong argument. The argument name
is "aStructure", but it is rarely a structure. It appears that most of the
time it is an Action (e.g., PageEdit, Login, etc.). The only time that I
noticed a structure was when I added something to the folder using the
Contents page.
I would recommend renaming Storage>>changed: and Storage>>changed. These
messages are already defined on Object for dependents handling, but these
methods are doing something different.
Finally, I'd recommend against modifying collections outside of their
containing object. For example, the FolderEdit>>moveDown: reaches inside the
Folder object and manipulates the children collection. The Folder should be
the only object that manipulates its children collection. Externally
modifying the collection makes it hard to change the representation in the
future.
John Brant
Hi John,
> There is a bug when deleting pages. Here is a test case:
> 1) Add a *Test* link to the Introduction page
> 2) Click the Page link to create a new Test page
> 3) Save the Test page
> 4) Go to the Information folder and "remove" the Test page
> 5) Go back to the Introduction page and click the Page link to create
> a new
> Test page
> 6) Save the new Test page
> 7) Go back to the Introduction page -- the Folder, Page, Resource
> items are
> still there. However the Information page contains a Test page. If you
> click
> the Page link again, it will create a Test1 page, but it won't update
> the
> Introduction page.
- This bug has been fixed. At the same time I have cleaned the code
with the internal links a little bit, as this was not the only case
where they showed wrong behavior. The look-up of the link-target is now
done dynamically whenever the page is rendered, so I am always
up-to-date. However the new implementation does not update
automatically when renaming the target. In a future version a visitor
could be added to fix that kind of problem. Of course I've also added
some new tests.
- I have added a couple of missing tests, especially for the serving
part with the chain-of-responsibility pattern. This raises the overall
coverage of the tests to about 75% immediately.
> Also, the cache uses a simple scheme for assigning keys (+1). Isn't
> this
> scheme too simple for web apps? For example, I could look at the page
> source, and come up with callbacks that are likely to be valid. For
> example,
> if I see callbacks for 341-344, I could try evaluating code for 340.
> This
> might execute a callback for some other person. Shouldn't the keys be
> some
> large random number instead?
- The tricky thing about the callbacks is, that they have to be
evaluated in the right order. To archive this, I sort the callbacks
according to their number to make sure that they are evaluated in the
same order as they had been defined on the page. In most cases this is
no security-issue as the the global permission of the action is checked
before evaluating the callbacks. However, and in that part your
concerns were absolutely right, there are some links in the EditFolder
action that require special permission (remove, copy) and that had not
been checked properly before. I've added some additional code to handle
this.
The optimal solution would be to have a huge and random session key
combined with small callback-numbers unique to that session. Probably
this will come in the future, when there is a proper session support in
SmallWiki.
I've committed the changes to Cincom StORE.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
There is a bug when deleting pages. Here is a test case:
1) Add a *Test* link to the Introduction page
2) Click the Page link to create a new Test page
3) Save the Test page
4) Go to the Information folder and "remove" the Test page
5) Go back to the Introduction page and click the Page link to create a new
Test page
6) Save the new Test page
7) Go back to the Introduction page -- the Folder, Page, Resource items are
still there. However the Information page contains a Test page. If you click
the Page link again, it will create a Test1 page, but it won't update the
Introduction page.
Also, the cache uses a simple scheme for assigning keys (+1). Isn't this
scheme too simple for web apps? For example, I could look at the page
source, and come up with callbacks that are likely to be valid. For example,
if I see callbacks for 341-344, I could try evaluating code for 340. This
might execute a callback for some other person. Shouldn't the keys be some
large random number instead?
John Brant
