Wikka Code Structure


A few days ago I had a little discussion with JsnX in TheLounge (the #wikka channel on irc.reenode.net) about "external" type programs (not part of Wikka but providing important functionality), actions, plugins... and how to organize it all better into a directory structure. I'd been thinking about the same things myself, but somehow didn't quite pick up on what JsnX was proposing (I was probably "multitasking" and doing other things while talking to JsnX on #wikka, sorry).

So, I'll now try to take it from there and give a worked example of what I had in mind (and possibly JsnX as well).

Rationale

My rationale for this proposal is as follows:
So here is how I'd structure the directory (some comments included in PHP-style):

Proposal

[wikka]/

[wikka]/3rdparty/

[wikka]/3rdparty/core/
[wikka]/3rdparty/core/safehtml/			#HTML can be turned off globally

[wikka]/3rdparty/plugins/
[wikka]/3rdparty/plugins/freemind/		#cannot be turned off yet but is not needed functionality
[wikka]/3rdparty/plugins/geshi/
[wikka]/3rdparty/plugins/onyx-rss/		#replaces [wikka]/xml/ 
[wikka]/3rdparty/plugins/wikiedit2/		#can be turned off globally

[wikka]/actions/

[wikka]/actions/core/
# "overall management" actions (referring to other pages than the current one)
[wikka]/actions/core/category.php
[wikka]/actions/core/highscores.php
[wikka]/actions/core/interwikilist.php
[wikka]/actions/core/lastusers.php
[wikka]/actions/core/mychanges.php
[wikka]/actions/core/orphanedpages.php
[wikka]/actions/core/ownedpages.php
[wikka]/actions/core/pageindex.php
[wikka]/actions/core/recentchanges.php
[wikka]/actions/core/recentcomments.php
[wikka]/actions/core/recentlycommented.php
[wikka]/actions/core/textsearch.php
[wikka]/actions/core/textsearchexpanded.php
[wikka]/actions/core/nocomments.php
# page content (or referring to/changing the current page only)
[wikka]/actions/core/backlinks.php
[wikka]/actions/core/color.php
[wikka]/actions/core/colour.php			#only does an include of color.php so don't have duplicated code!
[wikka]/actions/core/include.php
[wikka]/actions/core/image.php			#and disallow dynamic image inclusion via url: not valid html
[wikka]/actions/core/lastedit.php
[wikka]/actions/core/table.php

[wikka]/actions/plugins/
# system management
[wikka]/actions/plugins/emailpassword.php	#access control may not be desired/implemented
[wikka]/actions/plugins/usersettings.php	#access control may not be desired/implemented
[wikka]/actions/plugins/feedback.php
# page content
[wikka]/actions/plugins/calendar.php
[wikka]/actions/plugins/files.php
[wikka]/actions/plugins/flash.php
[wikka]/actions/plugins/googleform.php
[wikka]/actions/plugins/iframe.php		#now in intranet dir for security reasons: it's really an action!
[wikka]/actions/plugins/mindmap.php
[wikka]/actions/plugins/rss.php
# ... more actions added in version 1.1.6.0

[wikka]/library/
# library files with code to be included and called
[wikka]/library/common/
[wikka]/library/actions/
[wikka]/library/handlers/

[wikka]/templates/
# page structure rather than content (not for actions and handlers)
[wikka]/templates/footer.php			#not an "action"!
[wikka]/templates/header.php			#not an "action"!
# page content blocks and templates
[wikka]/templates/common/
[wikka]/templates/actions/
[wikka]/templates/handlers/

[wikka]/css/
[wikka]/docs/
[wikka]/formatters/
[wikka]/handlers/
[wikka]/images/
[wikka]/setup/


Notes
"Core" actions could be in the same registry, but with a marker that makes it impossible to deactivate or unregister them: that way the registry function could also display which "core" functions are available. A registration mechanism like this would also solve the problem of the (insecure) iframe action which is now hidden away in an intranet directory: it could be delivered with the file placed in the actions directory but unregistered in the registry.
Structure adapted now by placing header and footer into a new directory templates that better describes their purpose. In case we do move to some templating system for Wikka, we'll need a place to store the templates anyway.
Adapted for the new (proposed) structure of the library directory. The subdivision in common/actions/handlers is intended to facilitate some (future) automatic processes to find to-be-included code and to describe (in CVS) which files belong together.
The name "library" is (still) only preliminary, I'm open to better suggestions; the idea is to have a name that expresses its purpose as described here.
  • Hiya JW. The only reason I suggested "scripts" (at BannerMaker) is because that's what Costal uses in ComaWiki for "extras" like the bannermaker.php and java files and keeping some consistencies amongst wakka forks has some advantages for sharing/moving actions amongst the different forks (and I think there's some advantages to that). I have no objection to other names or directory structures. --GmBowen
  • How about libs? Or pluginlibs? --NilsLindenberg
    • Took your idea but changed it to "library" (my original idea "aux" seems to be a reserved name under Windows so could not be used). --JavaWoman
If we move to a 'real' template system, this may need to be revised of course (depending on that system's requirements for locating templates) but if we don't this will still be a "half-way" template solution that would make interface design for Wikka much easier.. --JW

Comments?

Comments and better ideas welcome, of course.

Function names


CategoryWikkaArchitecture
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki