We relaunched the TWiki.org project with an expanded TWiki charter, and we invite you to participate! The TWiki.org Code of Conduct agreement took effect on 27 Oct 2008. We ask existing twiki.org users to opt-in. You need to opt-in to participate in the Blog, Codev, Plugins and TWiki webs. -- PeterThoeny - 27 Oct 2008
Tags:
create new tag
, view all tags
Trying to further the architecture diagram in ArchitectureDiagram, I did a quick analysis of TWikiDotPm.

I propose that any particular module should contain at most one kind of stuff.

My main conclusion is that TWikiDotPm contains the following:

Type of Stuff Number of routines Proposed place for this stuff
CGI Initialisation   keep in here. Also move all initialisation from all CgiScripts into TWikiDotPm
Stuff for handling preferences data   move to PrefsDotPm
Stuff for extracting Name-Value Pairs   move to proposed DirectivesDotPm?
Stuff to make topic summaries   move to proposed MiscDotPm?
Stuff to manipulate dates   move to proposed MiscDotPm?
Stuff to help mirror webs out to different servers   move to proposed MirrorDotPm?
stuff to help CGI know where lib directory is   keep in TWikiDotPm
stuff to help CGI know where URLs for other scripts are   keep in TWikiDotPm
Stuff to username to wiki name translation (and back)   move to AccessDotPm
Stuff to help track length of time spent debugging   move to proposed DebugDotPm?
Stuff for rendering   move to proposed RenderDotPm

This would add:

  • RenderDotPm
  • DirectivesDotPm?
  • MirrorDotPm?
  • UserManagementDotPm?
  • NotifyDotPm?

Thoughts?

-- MartinCleaver - 18,23 Jun 2002

Most importantly, I feel, is the proposal to separate the initialisation for CgiScripts from everything else. Currently these are all done by TWikiDotPm, making it impossible to use one without the other.

I came a cropper with this when building a Plugin for SubmitTopicByEmail, because whenever a piece of mail came in I was required to do proper initialisation of the CgiEnvironment? in order to map from email name to wiki user name.

Second most important would be the creation of Render.pm because rendering is such a large part of what TWiki does it would aid to clarity to get this reflected in the code. It would also allow the RenderingPipeline to be used in new and interesting ways, for instance it would be possible to get TWiki to render in response to a WebService request, something that is not currently possible.

-- MartinCleaver - 01 Jul 2002

Topic revision: r5 - 04 Sep 2005 - 18:06:12 - PeterThoeny
 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback