I am struggling with my first TWiki upgrade and now I realized why so many Twikis run on obsolete install: It's a major pain!
I tried to create separate page for CustomPreferences to be included into
TWikiPreferences. Was rendered and looked OK but variables did not "take". I am not sure if it is a bug or new feature, I assume that when script is parsing preferences it ignores INCLUDE, and maybe it's even good for speed.
Here is how I hoped it could work:
Together with
TWikiPreferences we'll have separate page, TWiki.CustomTWikiPreferences. This page will be shipped empty, and admin will be supposed not edit
TWikiPreferences, but instead every changed option copy to TWiki.CustomTWikiPreferences, which will be INCLUDEd in the bottom part of
TWikiPreferences. When script will look around, new custom values from definition in Custom page will overwrite supplied default.
OK, maybe it might be slow because this way we will parse too many pages to look for preferences. Valid point. So what if we create another script
compile_preferences, which will parse all preferences pages (Site and all webs), follows all includes, and creates some easy-to-parse or binary form, per web, which all script will use? This will simplify scripts and allow for modular preferences. And also allow to add newer system preferences variables - I'll either accept value provided by default, or put my into Custom page.
What do you gurus think?
Or is there another better way to go?
--
PeterMasiar - 15 May 2003
Also asked for at
IncludeFailsForPrefs. IMO implementing this will
greatly simplify upgrade.
I wonder is this so dumb idea, or is threre so obvious workaround that nobody is interested?
--
PeterMasiar - 28 May 2003
The idea of seperating local-site preferences from global twiki configuration is most definately not dumb. I'm personally leary of INCLUDE because I'm already unhappy with the performance of my twiki installations. Hopefully the thoughts of
AntonAylward depicted in topics like
MetadataSucks and
MichaelSparks in
DataAndCodeSeparation will find expression in code usable by non-developers before long.
--
MattWilkie - 28 May 2003
This is something I try to stress repeatedly!!! TWiki should be easy to upgrade!!!
That's what I have done with
KoalaSkin that I suggest we do for TWiki:
- Consider distributed files as non-modifiable. Preference files should thus not be included in the distribution. Either:
- distribute them with a
.distrib appended to their name (e.g: TWiki.WebPreferencesSample) and let the user copy them in place at installation. This is what is done by most software.
- have configure-like tools generate the initial configuration files (this is what I did for Koala).
- Try to keep preference files to the terser version possible, and have the instruction/docs in a separate topic possibly %INCLUDEd in the prefs (INCLUDEs are not interpreted when loading prefs I think) such as TWiki.WebPreferenceHelp. For instance the help text in WebNotify should not be part of the topic itself. This is to ease upgrading.
- Provide patch files to apply to preferences (or instructions for upgrade, or perl script to run) on new releases. This is equivalent to having your idea of a compiled form, only you only have to do it once at upgrade.
I think the main problem is that releases are too far apart, so that the Core Team lives with incrementally upgraded alpha releases
and do not experience first-hand the difficulties to upgrade...
--
ColasNahaboo - 04 Jun 2003
Re:
INCLUDEs are not interpreted when loading prefs I think
Exactly. That's how I was hoping to simplify upgrade. And it's misleading, because
view script shows INCLUDEd preferences, just values are not defined.
--
PeterMasiar - 05 Jun 2003
Just to let you know, I'm developing a patch for TWiki to separate custom preferences. My idea is modifying the TWiki modules to read from TWikiPreferences, TWikiSitePreferences, WebPreferences and WebSitePreferences, so the installation and upgrades provide TWikiPreferences and WebPreferences (the latter, per web), and the initial installation, the four topics. The site administrator, then, would only edit the *SitePreferences topics, leaving the rest for fallback configuration values.
--
EstebanManchado - 06 Aug 2003
--
SueBlake - 06 Aug 2003
I'm putting the patches and comments in
SeparateCustomPreferencesPatch.
Hey, Sue, does that mean that you want to see the patch? I'm not sure I get it, mostly because of the "

" and the "

"
--
EstebanManchado - 06 Aug 2003
Didn't you read comics when you were a kid? See, it's a time sequence.
Thanks Esteban, this is exactly what I need! I'll use it everywhere.
--
SueBlake - 06 Aug 2003