27 Oct
2003
27 Oct
'03
1:58 p.m.
I was just going to say:
that information should be in the workspace. I want my students to be
able to load SmallWiki, read a bit on the workspace, start serving
their thing and start playing. So everything related to that should be
there. Most of it is, but some of these new things are not. Other stuff
that is good to know should be on a FAQ page somewhere, yes.
On Monday, Oct 27, 2003, at 10:33 Europe/Zurich, ducasse wrote:
OK
Ok
Roel Wuyts
DeComp
roel.wuyts(a)ulb.ac.be Université Libre de
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/
Belgique
Board Member of the European Smalltalk User Group: www.esug.org
Basically the
url to your resource, that means if you upload the
style-sheet to your root folder as a resource and give it the title
'Style Sheet', it is accessible with:
@import "http://localhost:8080/StyleSheet";
For a production server you have to replace the host-name with your
real domain-name, else people from outside won't see your design.
We should start a FAQ on SmallWiki :)
Lukas I saved the image and reopen it and it
seems to me that the
import I specified was lost. Is it possible or my mistake?
This should not happen, as the template and the style-sheet are saved
as a property within the structure where you defined it.
One thing that could cause that problem is if you use this line to
start your server again:
server := SmallWiki.SwazooServer startOn: 8080.
As I write in the comment is only intended to be executed the first
time and should be removed afterwards, because it initializes a
completely new wiki. Just use
server start.
to restart the wiki again, after you opened an image. Of course,
shutting-down and starting-up the server could be made automatically,
but it is not easy in VW as it is in Squeak, I think.
I do not know but I can think that this is more robust in VW but we
should simply ask.
You are basically suggesting the
naming-conventions of the design
patterns book. When I implemented those visitors I didn't had that
book yet, so I copied the conventions of the refactoring-browser. I
don't know what is better and what the idea of John Brant was when
writing his visitors.
Of course it is easy to change the message-names, but I don't know if
that really helps much. I can life with both conventions, in 'ROE'
the design-pattern and in 'Formulator' a modified refactoring-browser
approach is taken.
Sure I can live with that too, but imagine all the newbie that will
follow my lecture and the lecture of roel, so this is only a cosmetic
change but it is really worth because it helps the people to know
where they are. I realized that because I was coding at least 5
visitors for the bibtex stuff of roel and I was confused not to find
the same.
- I saw
that the parent of a resource is not the page having a
reference to it but the folder in which the resource is located. I
can understand why: multiple pages in the same folder can refer to
the same resource. Now is there a simple way to know from which page
a resource is accessed?
Pages do not have children and they might even reference resources
from different folders than their parent.
If you want to know all the structures referencing a specific other
structure (this doesn't have to be a resource necessarily) just use
something similar to the code below. One could even add a message to
Structure itself to get all the references more easily:
Structure>>references
"Return all the structures referencing the receiver."
^(VisitorReferences collect: self root to: self)
collection
We should add that.
> - how can I find the name and not the title of an uploaded image?
The name? You might call #id to get the id of the image or call #url
to get the full path of it. But the filename where it is was uploaded
from is not stored anywhere, I think this is not really needed and
platform-dependant anyway.
It is important because imagine I want to upload a collection of
picture and then after some reason
I want to transform them (thumbnail or what ever) and I want to save
them. I do not want to have image1, or just the title. Here we are
losing an important semantical information. Note that I did not talked
about the path but the file name like stairInteractif.tif vs stair.tif
(those are just images of my books and their names are really
important).
Cheers (& see you tomorrow in the Java lecture :P),
I cannot attend it, but I will follow all the other ones.
Lukas
--
Lukas Renggli
http://renggli.freezope.org