Re: [Phpwiki-talk] Re: Link tokenization

[Steve W. <sw...@wc...>]

Great summary, Arno. As long as we architect 1.2 with this possibility in
mind, I'm happy.

sw


On Mon, 17 Jul 2000, Arno Hollosi wrote:

> 
> I gave this some more thought. Here's what I've come up with.
> Let me state again that the wikilink table can be used
> with or without link tokenization. The benefits of this table are not
> bound to tokenization.
> 
> Pros:
>    * Eliminate name collisions when merging wikis -- long term benefit
>    * Easy automatic link fixing when a page is renamed -- short term
>      benefit for a seldom (or not so seldom) used feature
>    * pages (and their referencing links) can be deleted easily -- short
>      term benefit for a seldom (or not so seldom) used feature.
> 
> Note that the last two points "Seldom vs. often used feature" depends
> on what kind of wiki you are running. In common wikis they would be
> used seldom I reckon.
> 
> Page deletes *without* deleting references can be easily done without
> tokenization too.
> 
> Con:
>    * Complexity and if it becomes too complex bugs may cause "Bad Things".
> 
> 
> Other things mentioned:
> 
>  > Undefined pages can be listed separately (ListOfUndefinedPages)
> 
> This can be done without tokenization as well.
> Or is there more to this and I've overlooked something essential?
> 
>  > >  3. Inversion of the pre-transform [is hairy]
>  > >     (Eg. was the link entered as "WikiLink", "[WikiLink]",
>  > >      or "[  WikiLink ]"?)
> 
> This is a moot point. Say links are always displayed as [WikiLink]
> to editors afterwards. What's the drawback?
> 
>  > >  2. Bugs in transform code are more likely to cause
>  > >     permanent changes/losses of page content.
> 
> Only if the transform code becomes too complex.
> 
>  > >  3. Faster page rendering.
> 
> Wether or not this is true: it's a moot point.
> 
> 
> To sum it up: some (small?) short term benefits plus a long term
> benefit weighed against added complexity.
> 
> I vote for postponing this change until 1.4. 
> Eventually it will be done, but 1.2 is too early for this.
> 
> Let's concentrate on the high priority issues first:
> - making phpwiki more modular for easier extension and customization
> - refactoring the db interface (going oop?)
> - adding new navigation possibilities through use of our
>   new db schema.
> 
> When this is done we can roll out 1.2.
> And then we can start the really crazy things.
> 
> Jeff, I'd really like to see the class definitions of your
> transform code.
> 
> 
> /Arno
> 
> P.S: I have to switch vacation with a colleague. This means that
> I'm on vacation from Thursday until end of July. Probably without
> email access, but unable to code on phpwiki for sure :(
> 
> -- 
> secret plan:
> 1. world domination
> 2. get all cookies
> 3. eat all cookies
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
> 

................................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain