Hi,
as I understood the folders, they can be used like name-spaces, no?
I created a folder "scg" (to mirror our swiki), then there I wanted to
create another folder
"Howtos" for scg-stuff. BUT: howtos was already taken on a higher level.
Is this my misunderstanding or a bug? How should I proceed?
Cheers,
Markus
Hello,
There's a new version of SmallWiki 2 available in Cincom store, which fixes
some minor bugs of earlier versions and adds some new features: Links are
now implemented, the same is true for Smilies. There's a new renderer to
search the wiki and two new components are implemented: one can find broken
links in the entire wiki, the other lists all outgoing links.
So the basic things are now implemented and should work, but there are still
a lot of missing things.
Currently I'm working on a new user interface, so if you have some
suggestions / wishes for that, please let me know.
Then I have two questions to Lukas:
- I have noticed that you have removed inst var 'resolver' from
InternalLink, which was there in SW1 and was used to determine the target of
the internal link. Now there's a setting method for the target instead. So
is your intention to set this target every time when a link is created, in
WikiParser>>createLink ? I'm not sure if that's the ways to go because you
haven't done any preparation for that in WikiParser.
- Some components that aren't implemented yet I don't understand. For
instance the NearbyLinksComponent, what should be its purpose? When is a
link "nearby" another? Or the PopularLinksComponent. To implement such a
thing, we need something like an access counter for every page. Is your
intention to add such a counter?
kind regards,
David
There does not seem to be an admin view that provides info on whom created
a particular version of a page. For example the admin history view shows:
Title: My Second Page
Modified: July 26, 2004 11:25:17.051 by admin from 127.0.0.1
Version: 24
Document: Edit your page ... *My link>myGif* MOre stuff other stuff stuff
from admin..
The documents are already tagged via their properties with their creator,
I personally would like to see a "creator" or "author" field in the above
view.
-Charles
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
We spent a day at Camp Smalltalk working with the old version of SmallWiki
and have been spending some time with the new one.
In the old one, Folder was a subclass of Page. This was reasonable. In the
new one, Page is a subclass of Folder, and this seems wrong. It looks like
Folder is never used, and all Pages can be Folders.
The worst part of the old SmallWiki was the callbacks. They are a horrible
design, virtually impossible to understand. I had hoped that the Seaside
version would fix them, but it didn't. Actions went away, and they weren't
that bad, aside from the callbacks. So, tell us why the Seaside version is
an improvement? In my opinion, it is a big step backward.
One of the bad features of the Seaside version is that actions are performed
in the user interface, not in the model. For example, a page is edited in
the #save version of EditRenderer, but in the accept (or maybe document:)
method of DocumentEditor. It looks like DocumentEditor does not create
history, so the trippy interface does something different from the Seaside
interface. This bug is due partly to bad design. There should be a single
place where documents are edited, like an Action. The model should change
the model.
We got an error in the new SmallWiki whenever we tried to put a new link on
a page. Is there a newer version?
-Ralph Johnson
Hi everybody,
I published a first version of SmallWiki 2 to Cincom Public StORE
(SmallWiki2, 1.12, renggli). I hope it loads without troubles :/
Don't expect much! And *don't use it on your production server*, the
model might still change and I won't care about backward compatibility
before reaching the final 2.0 version!
Some of the consideration of the new implementation:
- the model is completely separated from the view: e.g. there is a view
based on Seaside and for demonstration purposes a very simple and buggy
one on the trippy-inspector framework.
- the model of the structure has been refined to allow better
versioning, external storage, etc.
- even better extensibility ;)
- the model of the document and the parser has been improved to allow a
more generic use of the entities: smilies, code are now possible within
headings and links; links are now possible within headings, etc.
- the parser tests have been improved and all the production rules are
covered now.
- the old model is easily transformable into the new one by writing a
visitor (not proven yet, but I expect it to be very easy).
I'm looking for any comments and feedback on the new implementation.
I'm looking for people as well that are willing to help and/or comment
in the following areas:
- Improving the model.
- Writing more tests.
- Improving the Renderers: e.g. error-checking, more functionality,
better user experience, etc.
creating a nice userinterface.
- Finish the existing but incomplete and add more subclasses to
WikiComponent. Currently most of them are empty classes without any
useful functunatliy.
- Improving the trippy-inspector wiki, that is nice to use but
currently badly implemented.
- A SmallWiki 1 to SmallWiki 2 model convertor.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Talking about security, it would be nice not to have unecrypted passwords
fly into the wiki. I noticed that Swazoo has apparently support for SSL
i.e https. Therefore, I was wondering if it is feasible to run the wiki
under https or to at least login into the wiki via https and once the user
is authenticated to re-direct to the normal wiki. My main concern is just
the clear text passwords. Of course, the next question is does Seaside
have any support for https?
thanks
Charles
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
I'd like to have a folder for a particular course. Inside this folder is
another folder called "students", and inside this folder is a folder for
every student in the class. Let's say there are 40 students in the class,
so 40 folders in "students". I want to give each student the ability to
administrate his folder, and to keep other students from reading files.
It appears to me that the only way to do this is to create 40 roles, one for
each student, and to say that role N can administer folder N. This is
because roles are defined relative to structures, but users are global.
What I'd really like to do is to define a role "owner" and to say that user
N has role "owneer" inside folder N, but not in any other folders. However,
I don't think this is possible.
Any comments? Do I really have to create 40 roles? I suppose I can make
an admin action to do this.
-Ralph Johnson
There are half a dozen of us here working on SmallWiki. We spent yesterday
working only with the old version, but a couple of people are going to start
looking at the new version today. We have been mostly focusing on
persistence, and have made good progress.
We are using the "Prevaylor pattern", though of course Smalltalker have done
this long before Java was invented. We are basically keeping a change log
so that we can recover from a crash by restarting the last saved image and
replaying the log. That is not quite complete yet. We also store resources
in the file system, not the image. That is complete.
With the old version, we often found that an action would produce a blank
page. For example, logging in usually did this, and sometimes editing a
page or resource would do this. We are hoping that the new version will fix
this. Is it a known problem with the old version?
-Ralph Johnson
