> SW2DocumentTests>>testChildren
> ...
> comp add: #first.
Yes, you are right of course. I must have been too lazy to actually
instantiate proper items to add to the composite elements ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hello,
On http://smallwiki.unibe.ch/smallwiki/ I added 3 zip files under the section Download SmallWiki One.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Anthony,
> I understand that SW2 is not yet public. So if your response is "wait
> until later", I understand.
yeah, that's a bit dangerous ;-)
> I downloaded a readymade image from
> http://www.iam.unibe.ch/~scg/Teaching/AdvancedLabs/swimages. That
> actually worked, and we got a few pages modified. But today, it
> started
> blowing up every time I hit the BACK button on the browser. Well, it
> blows up on re-using a link after the BACK button is used.
so far I didn't bother about the back-button, the only workaround is
to avoid the use of the back-button or to fix the problem by adding
#registerObjectForCallback: at all the required places. I will
certainly work on this soon.
> OK, fine. I decided to upgrade.
>
> I unzipped a fresh copy of
> http://www.iam.unibe.ch/~scg/Teaching/AdvancedLabs/swimages/
> SmallWiki2.2005-04-15.zip.
> Then, within Monticello I updated to Magritte-All-lr.19,
> SmallWiki2-All-lr.76, and Seaside2.6a1-avi.39, in that order.
As the comment says, Magritte-All-lr.19 is broken, try loading
Magritte-All-lr.19 and maybe SmallWiki2-All-lr.72. I am using
Seaside2.6a1-avi.26, but that shouldn't matter.
> But now, as soon as any link is chosen, the same error appears:
> MessageNotUnderstood: SW2Page>>filename
> * SW2Page(Object)>>doesNotUnderstand: #filename
>
> Is this fixable? Should I just pack my bags and go home?
This is certainly fixable. Could you send a full stack trace? I can't
reproduce this problem.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
hi rafael,
> wir machen im ADL den import vom swiki zu smallwiki 2. im swiki
> kann man seiten erstellen, wo text und mehrere bilder gemischt
> sind. kann man das auch in smallwiki 2?
add your images as files (probably as children to its page) to the
wiki tree and then link them using the standard syntax. Embedding is
possible of course, but you have to tell the internal link to do so:
anInternalLink embed: true
Btw, in SmallWiki 2 not only images can be embedded, but also other
pages, Seaside components and applications, etc.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
On 13.05.2005, at 14:38, stéphane ducasse wrote:
>>
>>> For the refactoring of pages we need to know the (direct) parent of
>>> each SW2WikiObject (especially SW2DocumentItem subclasses).
>>> SW2WikiObject has the instance variable owner, but it is not always
>>> used.
>>> We thought it would may be of general interest to always have this
>>> attribute. Would it be possible to get this feature?
>>
>> In my opinion, back-links are generally a bad thing and therefor I
>> try to avoid them whenever possible. Have a look at the i-var parent
>> in SW2Structure and SW2Decoration and all the hassle around this.
>> Back-links duplicate information and it makes several things, such as
>> copying, more difficlut.
As far as we know, DocumentItem matches a composite pattern. Most
composite patterns do have parent links (e.g. Java AWT and there seems
no problem).
>>
>> Actually, while traversing a composite with a visitor you have given
>> all the parent nodes implicilty in the context-stack. I don't suggest
>> that you are using the context, but to keep the last node in an i-var
>> or build up a stack of the current path to your visited nodes.
> I'm not that sure because in a AST having a back pointer can save you
> a lot of work.
> Now the question is if the back pointer changes a lot of not. Because
> normally this should not
> be difficult to have one single entry point to set it up and remove it.
> My experience with AST visitor based walking taught me that I like
> bakc pointer.
We are searching for elements with a visitor, but the refactoring
itself happens independently.
We need the knowledge about the parent of each DocumentItem while doing
the refactoring (e.g. for removing). We can not do the refactoring
with a visitor, because we want to present the search result to the
user for selection. If we have to deal with this without back links, we
need to collect the parents in the search-visitor and keep this
information temporarely in the search result. This would not be nice as
it is not the responsibility of the search result to know the parent of
the found elements.
Daria & Norbert
Thank you for your answer.
I can do line in the table with seaside?
Gianluca
> No smallwiki commands exist for this. However, you can play a bit with
> stylesheets. Using html as wiki text wil give you all the colors you want.
> I dont know of any tutorial, but you might find some anwers at
> http://smallwiki.unibe.ch/smallwiki/faq.
>
> Adriaan.
>
> > Hi,
> > I need some information about graphic, I would to do tables with colors
> > and lines with smallwiki, but I cant the correct commands. Can you tell
> > me how can I do or where can I find a tutorial for this information
> > please.
>
> --
> http://vdg38bis.xs4all.nl
>
>
____________________________________________________________
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it
Hi,
I need some information about graphic, I would to do tables with colors and lines with smallwiki, but I cant the correct commands. Can you tell me how can I do or where can I find a tutorial for this information please.
____________________________________________________________
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it
Hi Daria & Norbert,
> For the refactoring of pages we need to know the (direct) parent of
> each SW2WikiObject (especially SW2DocumentItem subclasses).
> SW2WikiObject has the instance variable owner, but it is not always
> used.
I don't see any i-var called owner in my code. I think you are
talking about the empty accessors in SW2WikiObject? These accessors
are implemented in SW2InternalLink, since internal links need to know
their page to do the lookup of the path. So, in this case the owner
is not the parent, but the containing structure.
> We thought it would may be of general interest to always have this
> attribute. Would it be possible to get this feature?
In my opinion, back-links are generally a bad thing and therefor I
try to avoid them whenever possible. Have a look at the i-var parent
in SW2Structure and SW2Decoration and all the hassle around this.
Back-links duplicate information and it makes several things, such as
copying, more difficlut.
Actually, while traversing a composite with a visitor you have given
all the parent nodes implicilty in the context-stack. I don't suggest
that you are using the context, but to keep the last node in an i-var
or build up a stack of the current path to your visited nodes.
HTH,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
> We are trying to hide objects from the user via an escaping
> visitor. Our
> first idea was something like:
>
> SW2Visitor>>visitSecurityDecoration: aSecturityDecoration
> (self context isCurrentUserAllowedTo: aSecturityDecoration parent)
> ifFalse: [ self escape ]
Yep, that would be the idea.
> The problem is that that
> SW2CurrentContextHolder value
> is sometimes nil, eg for SW2PathLookup.
>
> Any ideas?
What about setting it in SW2Visitor and make sure that all subclasses
do a propre super call? I think the default ones should do this anyway.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
When I added a menu to my wiki and set it's preference to always show
the whole structure beginning from the wiki root (via the
CompenentEditor).
An edit of the entry page results in an infinite recursion of
deepCopy; as far as I can tell, the new page created gets a copy of
the preferences, and with this special preference turned on, there's a
reference loop which causes the recursion...
Kind regards, Markus
- --
http://reauktion.de/archer/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCUjR0RiRItLFyH5gRAtj0AKCOjxpsXoYo68DaDw5bTZHXzrmVwgCfQrOO
GQ5fE0W38fumFbIK28hbbkA=
=Sv1U
-----END PGP SIGNATURE-----