[pmwiki-users] Selecting a Wiki engine...

Henrik Bechmann henrik.bechmann at sympatico.ca
Tue Oct 3 14:07:33 CDT 2006


I personally think the thing to do is wait until your current round of 
development is over, and then revisit the whole subject of hierarchies 
in consideration of all the tools available. Yet another opportunity for 
a magazine article!

Thanks,

- Henrik

Patrick R. Michaud wrote:
> On Tue, Oct 03, 2006 at 12:22:54PM -0400, Henrik Bechmann wrote:
>   
>> Patrick,
>>
>> See http://wiki.splitbrain.org/wiki:namespaces
>>     
>
> Ahhh, I see.  They essentially manage this by avoiding the problem
> of parent, ancestor, uncle, or cousin links -- i.e., you can
> address pages at or below the current group, otherwise you have
> to start at the root.
>
> Could work.  It still has a bunch of issues in a PmWiki context,
> however.  For example, a single name could be referring to either
> a group or a page, and it's not clear how one would manage group
> attributes.
>
> (I can give a longer detailed list if people think it would
> be helpful.)
>
> Thanks!
>
>   
>> Personally, I think it would be more fruitful (and less brittle) to 
>> think of the current PmWiki implementation as a *repository* of pages, 
>> with some way of structuring hierarchies on top of that with reference 
>> to the underlying repository. 
>>     
>
> This is what categories, trails, and other items are intended to
> help resolve.
>
>   
>> My hunch is that your page text vars may 
>> actually help in that regard (eg (:parentnode ParentGroup.PageName:)). 
>>     
>
> I think you may be right -- I'm still learning what all is possible
> within the context of page text vars.
>
> Pm
>
>
>
>   
>> Patrick R. Michaud wrote:
>>     
>>> On Tue, Oct 03, 2006 at 08:11:25AM -0400, The Editor wrote:
>>>  
>>>       
>>>> On 10/3/06, Thomas Voghera <thomasvoghera at gmail.com> wrote:
>>>>    
>>>>         
>>>>>> - limitation to a two-level hierarchy (groups and pages)
>>>>>>        
>>>>>>             
>>>>> Is this about how pages can be organized? carved in stone?
>>>>>      
>>>>>           
>>>> But it is *possible* this hierarchy problem will be solved soon.
>>>> There was a very long list discussion on the subject a few months
>>>> back, and the resolution seemed to be there was not a simple way (yet)
>>>> to adequately qualify relative links (and avoid resulting
>>>> ambiguities).
>>>>    
>>>>         
>>> It's possible but not likely.  I've spent a *lot* of time over the 
>>> past five years thinking about hierarchical group implementations,
>>> and I don't like anything we've come up with better than the current
>>> Group.Name system.
>>>
>>> That said, this past week I heard through a couple of off-list
>>> discussions that DocuWiki now has a good hierarchical grouping
>>> system -- if someone wanted to check it out and report back it
>>> might be worth looking at.
>>>
>>>  
>>>       
>>>> I'm wondering if in the back of Pm's mind the new syntax for *$:vars
>>>> was a step toward solving this problem.  
>>>>    
>>>>         
>>> Nope, I haven't consciously made a connection between vars and
>>> hierarchical groups.  Sorry.
>>>
>>> Pm
>>>
>>> _______________________________________________
>>> pmwiki-users mailing list
>>> pmwiki-users at pmichaud.com
>>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>>>
>>>  
>>>       
>> -- 
>>
>> Henrik Bechmann
>> www.osscommons.ca
>> www.bechmannsoftware.com
>> Webmaster, www.dufferinpark.ca
>>
>>
>>     
>
>   

-- 

Henrik Bechmann
www.osscommons.ca
www.bechmannsoftware.com
Webmaster, www.dufferinpark.ca





More information about the pmwiki-users mailing list