9/20 Is there a way in Twiki to have children inherit settings from a
parent? I know there is a WebTopicEditTemplate which you can use
for an entire Web, but what I want is to be able to have all of
the children under a given topic automatically be populated with
a template of settings when created. Is there a way to do that?
Right now I copy and paste my settings each time and not only does
that take time but there's a chance I forget to do it or else make
an error.
\_ Setting of arbitrary parent *topic*? I don't know of any feature
by default. For my purpose, I wrote a plugin that made twiki
use a custom EditTemplate depending on the suffix of a topic
name. I imagine similar concept can be used to check the the
parent variable. Search twiki site first to see if such plugins
already exist.
\_ Well, I just want the concept of a child topic inheriting a
template from its parent topic.
\_ But how do you specify *which* settings it inherit? When
you first create a topic, twiki loads the default topic
template and loads it in the edit box. Settings are
interpreted on the fly by running through the topic text
file twice. The settings are just part of normal text
as far as it's considered. You need a way to specify which
setting to inherit by perhaps wrapping it around a
TWikiVariable. And given that you can change the parent
of a topic by changing its metadata, interpreting it on the
fly is probably the best way to handle it given current
twiki behavior.
\_ It should inherit all of them. Every Set = from the
parent gets set in the child at creation time. If the
parent changes later then too bad.
\_ Keep in mind that TWiki didn't even have a concept
of parent/child until few years ago. At least for
the current implementation of new topic template
reading, it looked to me like you'd have to actually
overwrite that function within twiki's edit script
itself and can't be extended with just plugins. That
is, grabbing the variable defines from parent and
putting it in place during creation. What I was
suggesting where the settings are read on-the-fly
at each access *can* be done via plug-in. Choosing
the right wiki is a difficult task, partly because
the ideals of each wiki devel teams are different.
Wikis were originally meant to be unrestricted, which
is an ideal that TWiki developers still try to hold
to. That is one of the reason why there are commercial
wiki implementations popping up designed from groun-up
to have access restrictions. My main reason for
choosing TWiki? It's one of the few that supports
versioning of attachments, and rest of my group is
still very shy of php, which ruled out MediaWiki.
(And I believe MediaWiki has even less access control.) |