9 Apr
2005
9 Apr
'05
11:02 a.m.
Andreas
Lukas has been rewriting SmallWiki from scratch soon we hope to have a
alpha version.
Now **in Squeak** we do have problem with Squeak and SmallWiki one and
may be this will be the same in SmallWiki two.
The mechanism of saving the image (which works perfectly since more
than two year with VW and we did really crazy things
with the image such as loading code breaking SmallWiki one and other
ugly code that lukas fixed) since to stop working in
Squeak and we do not know why since this is really difficult to
reproduce and chase.
You can see in the archive at impara I guess the email I sent around to
ask whether people noticed this problem, and they did
and we do not know what to do.
So apparently on semaphore got blocked and SqueakSmallWiki stops to
save.
Now for SW2 we hope to have (at least the architecture is in place) a
changeset list mechanism).
Stef
On 9 avr. 05, at 8:14, Andreas Raab wrote:
Hi -
Yes, that works but the escape will be eaten just like what happens
with the <> vs. < and > when you edit the page again.
Not knowing the least bit about Smallwiki I wonder how this effect
happens in the first place - considering that it does happen with all
browsers I tried and that it does happen both for tags as well as
backslash escapes it seems as if there is a problem in the way
Smallwiki stores the data. If Smallwiki stores the "raw" (escaped)
data this shouldn't happen, but even if it stores the actual
characters escaping those for editing should not be a big issue.
Considering that I want to use Smallwiki for Tweak documentation which
will include lots of <on: mumble> and even more [yaddaya] I cannot
imagine having to fix all of these every time I save a page.
How do other people deal with this problem? Seaside for example - I
would expect that there are plenty of situations where at least blocks
are used and so this issue should show up in similar ways.
I will say that I know next to nothing about CSS - but knowing that it
isn't an intrinsic SmallWiki issue is the important part.
Thanks! This is very useful.
Cheers,
- Andreas
Q: What
are the rules for using [...]? How does one escape from the
Smalltalk block interpretation if that is needed?
use \[ and \] to escape the
block-characters. Generally the backslash
can be used to escape any of the wiki tokens like \*, \+, \=, ... This
looks good when rendered, but once the page is being edited
again, it will revert (!) to using <> instead of < and > and
thus, when saved the line vanishes in a puff of HTML-logic.
Q: Is this a known bug? Or is there something I'm doing wrong?
Yes, this is a
known problem. I don't know of a proper solution,
maybe one could try to double encode the text in text-areas. However
I am not sure, if there is a propre way to do this?
http://www.seaside.st/Documentation/GeneratingHTML/ the result is
pretty much garbage regardless of browser used. Firefox will only
print a single page; IE will do page breaks in the middle of text
lines and both will cut off part of the page.
Q: Is this an issue with the CSS used or with Smallwiki? Are there
strategies in Smallwiki or CSS to address this problem?
Indeed, this is strange
problem with the CSS of seaside.st, I have to
talk with the designer ;-) It works perfectly with the default CSS
coming with SmallWiki, have a look at http://kilana.unibe.ch/
Maybe for printing you want to define a different CSS anyway? e) The
Seaside Smallwiki at www.seaside.st has a nice little
navigation bar on the left which I would like to use too.
Q: Is this a standard feature of Smallwiki? If so, how does one use
it? If not, who do I have to bug to get the code? ;-)
This is the Menu-Component:
Log in as admin, go to Template >
Templates and add the template Menu. Configure the look of the newly
added component in Template > Settings. Attached you'll find the
settings we are using on seaside.st to get the desired effect.