Consider this a scratch pad at present. ie Total incomplete
See also:
HowShouldTWikiBeModularized,
ModularizationAndCommonTwiky,
PackageTWikiStore,
DataStorageForMultiLevelWikiWebs ,
DataAndCodeSeparation
Just some thoughts I've put together while exploring
TWikiModularizationCvsBranch. If I dont post some of them, they'll just sit on my hard drive forever.
This is just a discussion document at present, putting up some design concepts and defining a broad goal for this
ModularizationProject.
Goals and Ideas in Use
Its important when you start major reworking jobs like this that you define some clear goals and define the main ideas that provide the driving force behind the work.
The key goal is iterated in the
See Also topics is modularization. Creating clean code units with well defined dependencies and access interface. To get this seperation we need to find good modularization points. See
Modularization Units for further discussion.
Further goals, would involve improving interoperability and increasing the plugable (
TWiki:Plugins) nature of TWiki.
Its worthing looking at the ideas of MVC (
http://www.ootips.org/mvc-pattern.html) and some of the other ideas on that website. It goes without saying that object orientism naturally lends itself to modularization projects.
Modularization Units
A clear beginning is the storage system.
Store, Template, Topic, Render, Search
Concepts at Work
Web isa Topic
In the world of
MultiLevelWikiWebs, a Web is can be defined as a Topic with Childen. We can extend this concept further and say that a TWiki is a Tree of Topics or Tree full of Webs
--
NicholasLee - 21 Jun 2001
I'm really surprised that this doesn't include separating the code tree from the data tree to be honest - currenlt the lack of separation between the two things is the single largest thing I have to change when I perform a local Twiki install simply to make web sharing and backup be done in a way that provides us a long term means of handing over day to day running of our stuff to an IT group...
--
TWikiGuest - 17 Jul 2001
I dont think its an issue in the long run. i) a database storage system might not even use trees and ii) eventually there will be a properly installer and twiki might even live in /usr/lib/perl/TWiki/, the default templates might go in /usr/lib/twiki/.
Any way, this is as I stated work in progress. Essentially a draft RFC. What might or might not eventuate is dependant on what final code is written.
--
NicholasLee - 18 Jul 2001
That's the Problem - in the long run, it might not be an issue. In the short/medium term - ie now - it is an issue.
I'm in the process of duplicating the setup we have internally onto an external server and removing all the
sensitive content so that I can show people why it's useful, and necessary, rather than just bang on about
it. Regarding default templates - that's not really the issue - the issue is data dependent on webs being strewn
in multiple places making syncing harder since you can't just grab one location, you have to do 3 at minimum,
where you would want to do just 1.
BTW, by "data tree" above, I meant "the location that contains all the stuff to do with data for a
particular web" - which would mean by definition things like the data, the attachments, it's templates
and any auxillary stuff that happens to exist for that web. Look at it another way - suppose you wanted
to create a virtual host with login capability to the system and allow someone access to their own web
data. Having the current setup merging the base system of twiki (code + default templates + default stuff in
pub) with the client side system of twiki (webs, topics, and data) it adds unnecessary sysadmin overhead
onto the system.
Anyhow, once I've synced my internal code fork back to the current codebase I'll make the changes available
for perusal...
-- TWikiGuest - 17 Jul 2001
The
Func.pm
module has been created as an external API for TWIki to be used by Plugins. We could do a bit of very simple modularisation here by introducing one or two objects e.g. Topic and possibly Template.
--
JohnTalintyre - 18 Jul 2001
Michael, this topic is not about 'the now', its about one possible future. Also as I stated again this is work in progress. There can be no "really surprised" about what it contains until the spec is presented. I know about the current issues with 'low level' adminstration of a twiki, but I am interesting in solving the more structure issue of the modularization. Of which easy adminstration is only a component.
It is of course difficult to finialise an admin management interface when the basic structure of the data layout is undecided/incomplete.
John, I think what we should do is define basic semantics for passing information between components of the system. A plugin shouldn't say "I want $dataDir/Web/Topic.txt", it should say "I want $key" where $key is some generalised component.
I feel this is what is the important place to work from, but its not clear to me what the best way to go about this is yet while maintaining TWiki as according to
TWikiMission.
--
NicholasLee - 19 Jul 2001