Tags:
create new tag
view all tags

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. wink 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

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2003-09-06 - MichaelSparks
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.