Hi Stef,
You could even
put the style.css and the image as resource into your
wiki and serve it from the wiki itself, so you don't need to give a
local file-url.
Then what should I write in the import statement of the template?
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.
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 have any reference or doc at hand but I
found the following
code difficult because you mix accept and visit in the same method
Visitor>>acceptPage: aPage
self acceptStructure: aPage.
self visit: aPage document
I was programming using the visitor that roel defined for bibtext
processing and he uses
BibVisitor>>visitFile:
BibVisitor>>visitField:
Then the structure provide the acceptMethod:
BibVisitor>> visitEntry: anEntry
anEntry body acceptVisitor: self
I checked and in SmallWiki you have accept on the Structure and
accept* on all the visitor and this is confusing. Do am I wrong?
Visitor been a big double dispatch I would prefer to have:
Visitor visiting and Structure accepting (I also checked in the GOF
book)
So may be it would be good to deprecate some methods and offer new
ones. This would improve the readibility and avoid to get lost....
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.
- 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
- 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.
Cheers (& see you tomorrow in the Java lecture :P),
Lukas
--
Lukas Renggli
http://renggli.freezope.org