What I did so
far is the ChildrenDecoration that works pretty well. I
started now with the VersionDecoration that should represent the
previous version; I'm still unsure about the details of this
decoration, it is pretty tricky. Other decorators like security,
logging, virtual folders, etc. will be added later on. I think such a
design is much better as it separates the different concerns in a
cleaner way. I'm very interested what everybody thinks about this
(radical) change in the design?
this is interesting. I see the influence of seaside there :). If this
cleaned up the design and make simpelr perfect
As an example I would like to know if we could have this way:
- external resource (files contained explicitly out of the image)
Yeah, this is simple: a subclass of Structure that supports the same
protocol as Resource. As a lot of functionality has been taken out into
decorations, this are just the accessors #contents, #filename,
#mimetype. Or maybe we want such a hierarchy in the core? I don't care
yet :)
Resource
ExternalResource
InternalResource
- redirection
Yeah, I think this is something like a VirtualStructure, e.g. a
structure that is pointing (with an in-image-pointer) to a different
one in the wiki. In Unix terms, something like a soft-link. Uhh ...
cracy, one could even implement hard-links ;)
* I
implemented a more robust way of looking up pages trough a path.
The new lookup has been taken out of the Structure hierarchy and is
put into a visitor. It supports (unix-)paths starting at current
position 'abc/def', paths starting at the root of the wiki
'/abc/def', relative paths '../abc' and all combinations of those.
There are a lot of tests. I think this will make everything much more
easy to use, especially for the end users.
Excellent. Because I was always confused.
Yeah, no magic, no aquisition, pure unix (I hope that I support all the
unix aspects).
Now the next step is to do it the other way round: to write down the
shortest possible path as string to give a reference from structure a
to b, in order to avoid all those absolute paths that we had in
SmallWiki 1. What we gain is that references become pure
in-image-pointers, that makes moving stuff around almost trivial. Maybe
someone wants to volunteer for this task?
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org