Feature Proposal: Time to plan the new Foswiki core design.
Motivation
This proposal is a development of
ImproveOOModel topic but with more specific focus on new core design.
Description and Documentation
As the original proposal was more about the general idea and about choosing the implementation framework I want this proposal to be more about structural changes to the code which would let us clean it up and, in particular, prepare for PSGI transition.
Design objectives
- Convert Foswiki to use an object oriented framework. CPAN:Moo was chosen as the new framework.
- Rationalize and refactor functions to be local to their related objects.
- Prepare Foswiki to operate under the control of CPAN:PSGI for better cross-platform compatibility.
- Establish framework to move away from deprecated Perl modules, for example CPAN:CGI.
- Compatibility with the Foswiki and TWiki APIs is not an objective. Limited compatibility may be investigated later through an adaptation layer like the old TWikiCompatibilityPlugin.
-
Where to start.
- ImproveOOModel unless you're already familiar with the issue.
- Foswiki3CodeChanges provides examples of the code changes required during this redesign
- Branch task for the current development. This is where I record raw ideas, make notes on issues I don't understand yet or have plans to get back to them later, etc.
- A release meeting agenda which could be considered as a draft for this proposal. There is IRC useful discussion log too.
List of areas to be considered
With this list I would like to define general areas of interest to be considered.
- Compatibility with PSGI architecture.
- Divide Foswiki.pm into independent modules. One to be a container for static low-level API functions like
isValidWikiWord()
and the rest of is*()
functions. Another module to become a replacement of current session
which is actually not the session as people usually understand it.
- Topic object. Few related and interesting proposals are already floating around and might be reconsidered again.
- New plugins model. Should a plugin be capable to influence or even replace some core processes? For example, current store model could be replaced by new plugins. Same plugins may register additional macros for the frontend for purposes like providing some statistics or control functions to the admins. I leave the issue of compatibility with the old plugins aside but it it has to remain in place and it's only a matter of which way it has to be implemented.
- Clean and structured exceptions tree. This item would highly depend on all the previous ones.
Discussing everything design solution in this very topic would make this place a mess. So, I propose to have a separate topic on each subject. In this section every related topic is to be listed. Additionally I propose to have them
named starting with
Moo
prefix to unify and keep them close to each other in searches.
Impact
This will break compatibility with existing plugins. Plugins closely using the API will need minimal changes. Plugins that have any dependency on internals will need significant changes.
Implementation
--
Contributors: VadimBelman - 26 Feb 2016
Discussion