On 1/25/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 25, 2007 at 04:20:07PM -0500, The Editor wrote:
> >
> > Pm, don't know if you have been following this thread, but it has a
> > pretty exciting idea (to me) for hierarchical groups that would only
> > require minimal changes to the core. [...]
>
> One could easily get
> this to work without changing the core -- just create a
> script that does a custom version of pgcust.php and looks
> for configuration files in the order you're seeking, instead
> of PmWiki's default scripts/pgcust.php (which can be
> easily disabled, and in fact won't load any scripts that
> have already been loaded).
I'm sorry, but I couldn't quite follow all this. Could you explain a
bit more how to do this. I suppose I could handle creating the
function, just have never done anything involving built in PmWiki
scripts.
> If it proves useful enough we could see about adopting something
> like this the core, but I'm a little reluctant to commit to it
> until I see it working somewhere. In particular I
> think it might not be obvious to admins that the page
>
> XYZ-ABC.Foo
>
> automatically loads customizations from XYZ.php.
My suggestion would be we have a configuration option that allows you
to turn on $EnableHierarchicalGroups or something, so it wouldn't call
XYZ.php unless it was deliberately enabled by the admin.
Also, after having thought about it more, we really don't need
hierarchical groups and pages (as in the example I gave you), just
groups should be fine.
> > This should be about all we need for a really powerful, functional
> > hierarchical groups system.
>
> And the problem I have with "hierarchical groups" in general
> isn't the managing of the customization files, but relative
> links between pages of different groups. Your proposal
> doesn't seem to address that. (If we say that all links have
> to be absolute, then there's really no issue and we can make
> it all work using dots/slashes as separators, without the
> need to use hyphens.)
The little idea that sparked this renewed interest was how easy it was
to generate page variables by exploding a group name by hyphens. One
line can do
Pets-Care-Groom.Poodle
{$g1} = Pets
{$g2} = Care
{$g3} = Groom
My initial goal is simply to make relative links only able to point to
sister pages in the same group (exactly as now). Otherwise absolute
links would be required (also as now). The page variables only make
this somewhat simpler.
Or to use the example you suggested some time back:
Kingdom
+-Plant
| +-Grass
+-Animal
+-Canine
| +-Terrier
+-Feline
+-Cat
and Kingdom-Animal-Canine.HomePage were the current page, how would
your scheme refer to...?
(probably)
Kingdom (grandparent) {$g1}.HomePage
Plant (uncle) {$g1}-Plant.HomePage
Grass (cousin) {$g1}-Plant-Grass.HomePage
Animal (parent) {$g1}-{$g2}.HomePage
Canine (self) {$FullName}
Terrier (child) Terrier
Feline (sibling) {$g1}-{$g2}-Feline.HomePage
Cat (nephew) {$g1}-{$g2}-Feline.Cat
You will note there is no such thing as Kingdom-Animal being both a
page and a group. You are still ultimately using Group.Name for every
page. The hierarchical groups are simply in the sense you can easily
do pagelists, and breadcrumbs, etc., and more importantly assign
hierarchical config/css files.
My guess is in the vast majority of cases, the real need for
hierarchical groups is being able to make config and css files
inheritable. And where links are needed they can easily enough be
generated as above--at least by an admin.
And while it might not be as simple as we'd like for a newuser to
manually enter the kinds of links, it could be learned easily enough,
(for me, I envision ZAP automating this whole process quite easily).
The other thing I would like (need) would be a way to somehow do a
pagelist template for a list of hierarchical groups at some level, so
if searching Kingdom-Animal* I could get one instance of Canine and
Feline each. (perhaps also turned on when hg is enabled). Anyway,
being able to redefine optionally pgcust and do this kind of pagelist
would solve about all my hierarchical groups needs...
Thanks in advance...
Cheers,
Dan
PS. I went ahead and posted this back to the list to see if anyone
else had any feedback on this...
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
