Some musings on Twiki Architecture
Currently TWiki uses a sort of procedural or program driven architecture: data is passed as an arguement to a script as in view.pl/TwikiArchitectureNG...
In the process of musing over plugins and raw text viewing and forms and all, it has occurred to me that a more object/data centric architecture might be in order.
A template ("object") could have TWiki variables like:
EditHandler(scriptname)
ViewHandler(scrpitname)
etc.
Taking it another step, a page (.txt file) could have this metadata and include:
Template(mytemplate.tpl)
in addition to or in liu of the handlers suggested above.
Under normal circumstances, a user would never see the page metadata, but an admin or
TwikiWebMaster (a person or group having admin rights to a TWiki web) would have access to an enhanced edit page showing this information, perhaps in a separate text edit control in addition to the regular "body' text edit control.
A further tweak would be to allow scripts to be inline data, probably best only in templates. This would be useful for specialized (or potentially all!) processing such as a particular form - probably a mix of inline and callable scripts would be good. This would replace and become the plugin architecture.
Another nice benefit of this might be a single globally visible script; lets call it TWiki.pl, which parses and dispatches these handlers. Then you have a nice user url like:
http://mysite.com/Twiki/home
to bring up the top/first/home page of a TWiki.
This is manifestly not going to happen overnight, nor is this a fully developed idea, but hopefully it will spark some discussion and lead to a possibly better TWiki architecture...
Bring on the comments!
--
DavidLeBlanc - 15 Jul 2001
I agree that it is a worthy goal. Its a standard handler pattern, the name of which escapes me at present. Might be chain of command or something similar.
I was also thinking that the Topic post could be generalised using
TWikiAsWebServicesServer such that submission via email, http and
WebServices could be standardised. Using the handler idea you contributed here, these post methods just go in the
PluginHandlerChain.
I don't know the TWiki codebase at all really so I cannot comment as to how far away a goal this is.
--
MartinCleaver - 15 Jul 2001
I've got notes for a move to a fully oriented object basis for TWiki. Got a half finished Topic in a text on my machine discussion various parts of it. Since I'm far to busy at present to complete it any time soon or spend much time on TWiki I'll post the editorized stuff at
ModularizationConcepts.
Refactoring is one way of moving the code base towards a more structured basis. I think though that this will be extremely tricky as given the current interdependances between certain code units in the code any change to say the storage system requires multiple changes to various other aspects of the search and rendering units.
I think there is going to have to be a certain level of will required to "fully objectize" TWiki's code base. Certainly there could be arguements for or against doing this, but in the end I think it will be increasingly hard for people to add their own features to TWiki without understanding the whole/checking the complete code base if it stays as it currently is.
--
NicholasLee - 16 Jul 2001
Diagram now at
ArchitectureDiagram.
Just had a bash at representing what the architecture looks like presently. I'll have a go at drawing a similar diagram with
WebServices and more modularisation later. I hope the
CoreTeam don't mind my comments
--
MartinCleaver - 26 Sep 2001
I also see some strong advantages moving TWiki towards
TWikiOO. One of them is that the whole code is being reviewed. Another is that local changes can be made more easily. When changes are made to the objects, these changes can be remain effective when the core objects are upgraded.
(...) See also
TWikiOO
--
HansDonner - 26 Sep 2001
--
HansDonner - 03 Oct 2001