25 Jul
2004
25 Jul
'04
10:53 a.m.
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
26 Jul
26 Jul
7:39 a.m.
Hi David and others,
- 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.
I'm not sure about this yet, basically also because of the confusion if
folders and pages should be unified or not, what would have an impact
on the way of resolving links.
I know a lot of people that do not like the concept of folders and
pages, but personally I like them a lot and that's why I introduced
them into SmallWiki. Most people are confused with the folder, so I
tried to eliminate them in the current version. The comments of Ralph
Johnson made me think again and gives some more reasons to keep them, I
didn't thought of. Maybe we should discuss it this afternoon again ;)
- 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?
Hehe ... have a look what your enemy has in their standard wiki
implementation ;)
* NearbyLinksComponent: I thought that this component should list
wiki-structures that have a similar title to the current page.
* PopularLinksComponents: Pages that have been edited a lot in the
past. Of course the thing with the access counter would be an
interesting feature too.
I will have a look at your code now and continue with some coding. Also
I intend to update to the latest version of Seaside.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
9:49 a.m.
On 26 juil. 04, at 07:39, Lukas Renggli wrote:
Hi David and others,
But my impression is that these are really extensions of the core.
I do not see why we would have that per default?
- 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.
I'm not sure about this yet, basically also because of the confusion
if folders and pages should be unified or not, what would have an
impact on the way of resolving links.
I know a lot of people that do not like the concept of folders and
pages, but personally I like them a lot and that's why I introduced
them into SmallWiki. Most people are confused with the folder, so I
tried to eliminate them in the current version. The comments of Ralph
Johnson made me think again and gives some more reasons to keep them,
I didn't thought of. Maybe we should discuss it this afternoon again
;)
- 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?
Hehe ... have a look what your enemy has in their standard wiki
implementation ;)
* NearbyLinksComponent: I thought that this component should list
wiki-structures that have a similar title to the current page.
* PopularLinksComponents: Pages that have been edited a lot in the
past. Of course the thing with the access counter would be an
interesting feature too.
I will have a look at your code now and continue with some coding.
Also I intend to update to the latest version of Seaside.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
12:47 p.m.
Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
I know a lot of people that do not like the concept of
folders and
pages, but personally I like them a lot and that's why I introduced
them into SmallWiki. Most people are confused with the folder, so I
tried to eliminate them in the current version. The comments of Ralph
Johnson made me think again and gives some more reasons to keep them, I
didn't thought of. Maybe we should discuss it this afternoon again ;)
I don't see any need for two concepts. Why not ask the user
whether a new folder should be a sibling or a child, in the
same way the old version let's the user decide whether a new
name should represent a Folder, Glossary, Page or Resource?
Instead, ask "Child Folder, Sibling Folder, Glossary or Resource"?
We could add markup syntax to let the user make his choice
explicitly and skip the question, but that's just an optimization.
-dms
1:03 p.m.
I don't see any need for two concepts. Why not
ask the user
whether a new folder should be a sibling or a child, in the
same way the old version let's the user decide whether a new
name should represent a Folder, Glossary, Page or Resource?
Instead, ask "Child Folder, Sibling Folder, Glossary or Resource"?
yes, that would be more clear for a user. Maybe it's better to just ask:
"Page, Glossary, Resource". Because the term "page" is more clear
than
"folder" in this context, and a sibling page to the current page would be
created in the parent of the current page, not in it, I think. "Sibling
folder" might confuse users.
So a Page should have the possibilty to contain some children, like it does
now in SW2.
kind regards,
David
5:17 p.m.
=?iso-8859-1?Q?David_R=F6thlisberger?= <davidroe(a)bluewin.ch> wrote:
I think parent-creating-child would be most common, but Ralph
was interested in page-creates-sibling, too, to handle extension
and continuation pages. If you favor (I don't) a style where
you try to keep each page short, you'll be more inclined
to create siblings.
Of course, as long as its easy to move pages around the hierarchy,
it's not that important where you put the page initially.
-dms
I don't
see any need for two concepts. Why not ask the user
whether a new folder should be a sibling or a child, in the
same way the old version let's the user decide whether a new
name should represent a Folder, Glossary, Page or Resource?
Instead, ask "Child Folder, Sibling Folder, Glossary or Resource"?
yes, that would be more clear for a user. Maybe it's better to just ask:
"Page, Glossary, Resource". Because the term "page" is more clear
than
"folder" in this context, and a sibling page to the current page would be
created in the parent of the current page, not in it, I think. 
30 Jul
30 Jul
12:07 a.m.
I don't see any need for two concepts. Why not
ask the user
whether a new folder should be a sibling or a child, in the
same way the old version let's the user decide whether a new
name should represent a Folder, Glossary, Page or Resource?
Instead, ask "Child Folder, Sibling Folder, Glossary or Resource"?
"child glossary, sibling glossary, child resource, sibling resource".
I think the notion of asking "folder, page, resource" is ugly. I can't
think of a better general solution, though. My specific solution is to
allow the "anonymous" user to only create pages, and to make those pages
always be the sibling of other pages and the child of a folder. Only
advanced users will be allowed to create folders.
I have been thinking about what people have been saying on this list. I
found it hard to think why you could being saying the things you were, and
then I decided that your idea of a wiki was a tool for a few grad students.
My idea of a wiki is for a few thousand users, some of whom have no
experience with wikis. Simplicity is very important. I think you prefer
power to simplicity. That is reasonable for some audiences, but not for
mine.
-Ralph Johnson
12:28 p.m.
Hi ralph
I think that we are all looking for simplicity. This is really
important for us too.
So any solution that empowers the non-default users, but has a good
default and simple
solution should be the solution. :)
Stef
On 30 juil. 04, at 00:07, Ralph Johnson wrote:
I don't
see any need for two concepts. Why not ask the user
whether a new folder should be a sibling or a child, in the
same way the old version let's the user decide whether a new
name should represent a Folder, Glossary, Page or Resource?
Instead, ask "Child Folder, Sibling Folder, Glossary or Resource"?
"child glossary, sibling glossary, child resource, sibling resource".
I think the notion of asking "folder, page, resource" is ugly. I can't
think of a better general solution, though. My specific solution is to
allow the "anonymous" user to only create pages, and to make those
pages
always be the sibling of other pages and the child of a folder. Only
advanced users will be allowed to create folders.
I have been thinking about what people have been saying on this list.
I
found it hard to think why you could being saying the things you were,
and
then I decided that your idea of a wiki was a tool for a few grad
students.
My idea of a wiki is for a few thousand users, some of whom have no
experience with wikis. Simplicity is very important. I think you
prefer
power to simplicity. That is reasonable for some audiences, but not
for
mine.
-Ralph Johnson
10:16 a.m.
Hi David,
some comments about your code:
- I don't know if we want to do this again in SmallWiki 2. It caused
some confusion in SmallWiki 1:
InternalLink>>accept: aVisitor
self isBroken
ifFalse: [ aVisitor visitInternalLink: self ]
ifTrue: [ aVisitor visitInternalLinkBroken: self ]
- Mhh, I'm not quite happy with your extensions to the smiley-class. I
do want to keep the Model free of any HTTP dependent stuff and you
define the smilies using URLs pointing to the university server. I
would prefer to have the images within the code and serve them using
Seaside. A lot of people complained about being dependent of the
university server.
- A previously running test fails.
- You added a space into the tree component before the label. This is
the responsibility of the CSS-Stylesheet. No layout information in the
Smalltalk code. Not even a single space :) It is much more consistant
to put a ".label { margin-left: 10px }" into the style-sheet. Hey
Frederic, could you have a look at the generated XHTML code and create
some funky CSS? This would be really cool!
TreeComponent>>renderNodeLabel: aModel on: html
html spanClass: #label with: [
html anchorWithAction: [ self select: aModel ] do: ' ' , aModel
title ].
- For your code in the subclasses of RelatedComponent: You start your
search in the root of the wiki, but I think the default should be to
start in the current structure. Maybe we want to add a property to let
the user specify where to start.
- I suspect you didn't understand the idea of RelatedComponent. Why do
you have for all your subclasses two almost identical method-bodies
like #structures and #search...? Why do you customize the rendering for
each subclass? The only thing you need to do is to override the method
#structures and everything else should be handled by the abstract
parent. The strings you define in your rendering methods (e.g. 'There
are no external links in the wiki' or 'In ... these links are
outgoing:') shouldn't be there, this is the responsibility of the
CSS-Stylesheet as this is a property of the layout. Generally every
component should consist only of a configurable title-string (provided
by BodyComponent) and all the necessary information within div, span,
ul, li, etc tags.
Of course I'm open for your opinions, I just tried to explain how I
intended to implement the new generation of SmallWiki.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
11:07 a.m.
Hello Lukas,
I
would prefer to have the images within the code and serve them using
Seaside.
yes, that would be much better. I'm working on a better implementation of
the tree, which use some icons for the nodes, for plus and minus, to provide
a nicer design than using unordered lists. So there will be a lot of new
small images now... How can I hold these images within the code?
- You added a space into the tree component before the
label. This is
the responsibility of the CSS-Stylesheet. No layout information in the
Smalltalk code. Not even a single space :)
*g* ok, I get that. As mentioned above, the tree implementation I would
prefer to have, uses images now, so it ain't be possible to discard all
layout information from the Smalltalk code. To set an image in the code
should be okay, no? ;)
- I suspect you didn't understand the idea of
RelatedComponent. Why do
you have for all your subclasses two almost identical method-bodies
like #structures and #search...?
yes, you're right, that's bad...
Generally every
component should consist only of a configurable title-string (provided
by BodyComponent) and all the necessary information within div, span,
ul, li, etc tags.
okay, that's better, I see. I have already worked on a CSS-Stylesheet for
the new user interface, but I have not finished it so far. You can fetch it
from the university server. So I will try to control all the layout stuff
with this CSS file. Should I place this file also within the Smalltalk
code somewhere, or is better the store it externaly?
bye,
David
1:54 p.m.
yes, that would be much better. I'm working on a
better implementation
of
the tree, which use some icons for the nodes, for plus and minus, to
provide
a nicer design than using unordered lists. So there will be a lot of
new
small images now... How can I hold these images within the code?
Sure, but I don't really know how to do it VisualWorks in a
(preferably) portable manner.
- You added a
space into the tree component before the label. This is
the responsibility of the CSS-Stylesheet. No layout information in the
Smalltalk code. Not even a single space :)
*g* ok, I get that. As mentioned above, the tree implementation I would
prefer to have, uses images now, so it ain't be possible to discard all
layout information from the Smalltalk code. To set an image in the code
should be okay, no? ;) - I suspect
you didn't understand the idea of RelatedComponent. Why do
you have for all your subclasses two almost identical method-bodies
like #structures and #search...?
yes, you're right, that's bad... Generally
every
component should consist only of a configurable title-string (provided
by BodyComponent) and all the necessary information within div, span,
ul, li, etc tags.
okay, that's better, I see. I have already worked on a CSS-Stylesheet
for
the new user interface, but I have not finished it so far. You can
fetch it
from the university server. So I will try to control all the layout
stuff
with this CSS file. Should I place this file also within the Smalltalk
code somewhere, or is better the store it externaly? 
2:37 p.m.
Hi Lukas,
You can capture and store images in VW using 'UIMaskEditor open'.
hth,
Adriaan.
yes, that
would be much better. I'm working on a better implementation
of
the tree, which use some icons for the nodes, for plus and minus, to
provide
a nicer design than using unordered lists. So there will be a lot of
new
small images now... How can I hold these images within the code?
Sure, but I don't really know how to do it VisualWorks in a
(preferably) portable manner. 
3:16 p.m.
For icons in trees in VisualWorks you should:
(1) have a look at the class ListIconLibrary
(2) make extensions on this class to keep your icons in (just take some
existing ones as example)
suppose you choose myIcon20x20, and myIcon20x20mask
(3) you can then get this icon with the method #visualFor: #myIcon
which will use your picture and the mask to produce a transparant icon.
In the original StarBrowser I do this to have all kinds of icons in the
classifications tree.
If you want a more detailed example where your application controls
really everything you can have a look at StarBrowser2, where I install
custom visual blocks, like what you would do with a list.
Just send me a mail with what you want to do exactly in case you have
no idea what I'm talking about and I'll either do it or give you more
detailed instructions. I don't know how proficient you are with this
:-) In the meantime I figured it out :-)
On 26 Jul 2004, at 13:54, Lukas Renggli wrote:
Images should be part of the CSS as well, I think. So if you have a
green style enabled, you maybe want to have the tree-buttons in blue
as well. I would suggest to keep all the component layout to a very
minimal string-based css-enabled rendering and add images, colors,
etc. using style-sheets.
Mhh ... well, maybe my superclass RelatedComponent isn't very useable,
e.g. for external links you cannot return a structure. Maybe the
method should be #links and return a collection of link instances,
that can be anything: mail, url, structure, broken, valid, etc.
I don't know yet, maybe we should discuss. Nothing providing
CSS-Styles is there yet. Seaside is having some functionality, so
maybe we want to build something on top there.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
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
yes, that
would be much better. I'm working on a better
implementation of
the tree, which use some icons for the nodes, for plus and minus, to
provide
a nicer design than using unordered lists. So there will be a lot of
new
small images now... How can I hold these images within the code?
Sure, but I don't really know how to do it VisualWorks in a
(preferably) portable manner.
- You
added a space into the tree component before the label. This is
the responsibility of the CSS-Stylesheet. No layout information in
the
Smalltalk code. Not even a single space :)
*g* ok, I get that. As mentioned above, the tree implementation I
would
prefer to have, uses images now, so it ain't be possible to discard
all
layout information from the Smalltalk code. To set an image in the
code
should be okay, no? ;) - I
suspect you didn't understand the idea of RelatedComponent. Why
do
you have for all your subclasses two almost identical method-bodies
like #structures and #search...?
yes, you're right, that's bad... Generally
every
component should consist only of a configurable title-string
(provided
by BodyComponent) and all the necessary information within div, span,
ul, li, etc tags.
okay, that's better, I see. I have already worked on a CSS-Stylesheet
for
the new user interface, but I have not finished it so far. You can
fetch it
from the university server. So I will try to control all the layout
stuff
with this CSS file. Should I place this file also within the Smalltalk
code somewhere, or is better the store it externaly? 
11:31 a.m.
New subject: [Smallwiki] Images in methods
Hi Lukas,
Having images in methods are simple, but you must be aware, that images
are loaded separately from main page with parallel requests and separate
urls. So you need to do:
- first, put image in some method code,
- make an "virtual" resource which will actually call above method
- put url of that resurce to your main code.
In Aida I implemented that in above way and results are just fine -
having all your pictures in code solves problem of version control and
also simplify installation of your app.
If you are interested I can prepare some snipets from Aida code, but dor
start read http://wiki.eranova.si/aida/Method+Images and
http://wiki.eranova.si/aida/Method+Resources.
Best regards
Janko
Lukas Renggli pravi:
Hi David,
some comments about your code:
- I don't know if we want to do this again in SmallWiki 2. It caused
some confusion in SmallWiki 1:
InternalLink>>accept: aVisitor
self isBroken
ifFalse: [ aVisitor visitInternalLink: self ]
ifTrue: [ aVisitor visitInternalLinkBroken: self ]
- Mhh, I'm not quite happy with your extensions to the smiley-class. I
do want to keep the Model free of any HTTP dependent stuff and you
define the smilies using URLs pointing to the university server. I would
prefer to have the images within the code and serve them using Seaside.
A lot of people complained about being dependent of the university server.
- A previously running test fails.
- You added a space into the tree component before the label. This is
the responsibility of the CSS-Stylesheet. No layout information in the
Smalltalk code. Not even a single space :) It is much more consistant to
put a ".label { margin-left: 10px }" into the style-sheet. Hey Frederic,
could you have a look at the generated XHTML code and create some funky
CSS? This would be really cool!
TreeComponent>>renderNodeLabel: aModel on: html
html spanClass: #label with: [
html anchorWithAction: [ self select: aModel ] do: ' ' ,
aModel title ].
- For your code in the subclasses of RelatedComponent: You start your
search in the root of the wiki, but I think the default should be to
start in the current structure. Maybe we want to add a property to let
the user specify where to start.
- I suspect you didn't understand the idea of RelatedComponent. Why do
you have for all your subclasses two almost identical method-bodies like
#structures and #search...? Why do you customize the rendering for each
subclass? The only thing you need to do is to override the method
#structures and everything else should be handled by the abstract
parent. The strings you define in your rendering methods (e.g. 'There
are no external links in the wiki' or 'In ... these links are
outgoing:') shouldn't be there, this is the responsibility of the
CSS-Stylesheet as this is a property of the layout. Generally every
component should consist only of a configurable title-string (provided
by BodyComponent) and all the necessary information within div, span,
ul, li, etc tags.
Of course I'm open for your opinions, I just tried to explain how I
intended to implement the new generation of SmallWiki.
Cheers,
Lukas
--
Janko Mivsek
Systems Architect
EraNova d.o.o.
Ljubljana, Slovenia
http://www.eranova.si
7204
days inactive
7209
days old
14 comments
8 participants
participants (8)
-
Adriaan van Os -
David Röthlisberger -
dsiegel＠acm.org -
Janko Mivšek -
Lukas Renggli -
Ralph Johnson -
Roel Wuyts -
stéphane ducasse