Foren / Cotonti / Core Labs / Archive / Starting modulation

Shouldn't we ?

(e.g)
For starters, we can move functions to system/core/forums/forums.functions.php for functions specifically for only forums. (administration is another story, we'll get back that later)

We can later move tpl files to core/forums/design and when we make our module api ready, we'll be having little trouble than now.

imho

It will be eventually. This is the definition of "seperation" and modulation. And basic functions like sed_sql_query() will be in functions.php still, we will only move absolute functions. Agreeing to the fact that some functions are used multiple, there are some functions never used too. What I say is not if we should do it, shouldn't we start to do it.

Actually I wanted to open a discussion and share ideas about seperating, like which functions should be in the core.

There will be default design files, if preferred, you can add your own tpl file for the part (e: forums.posts.tpl) Similar to the page structure.

This will help people to create new skins and distribute more easily.

And it will not be even in system for long, it will be in modules/

No, I don't agree. Js is not a module but a collection of .js files.
Lang could be in core, but I think language (content) should be separated from core (logic).
System should be all logic that is used in multiple parts in the site (basically the current system folder without core and lang folders).
core != system, as core is only a parent folder for a bunch of other folders (as it is now) each containing a specific core module for the site, while system is only a collection of globally used files (functions.php, common.php etc).

Keep in mind we use the Model-View-Controller architecture, which basically splits code (files) into three sections:
- Content (database data and language files)
- Design (skins)
- Logic (core/modules/plugins)

In the case of Cotonti, it's preferable to have subsections in Logic, to separate core code, modules and plugins.

Our goal is to make things as simple and clear as possible and to put things where they belong. In the end, provided some documentation of course, it should make searching for files easier.

The number of templates is supposed to grow because more hardcoded things get templatized. And, yes, we should shorten the names in this case. Anyways, we'll try making it even more simple than it is now.

UPD

Alright, I have spent quite a while thinking the modularization concepts over and here is what I have come to.

1. Modules. Originally it was supposed that we are going to separate Modules and Plugins, then put big things to Modules and small things to Plugins. It would require separate APIs for them, etc. But what I have come to is that in fact everything should be a Module. In this way we would have a universal way to handle them all, no reason to duplicate APIs, have separate folders, etc.

So, a Module is just some part of engine that may have standalone parts (including root-level scripts) as well as parts that hook into other Modules. All the core modules (pages, list, forums, poll) will become Modules. All the plugins will be upgraded to Modules too. Changes listed in Plugin API changes will be applied on hookable parts of modules.

2. Dependencies. A Module may require some other Modules to be installed or at least present. For example, RecentPagesByPath would require Pages and Index. So Pages/Index would be installed before it (automatically if possible) and if one of them is removed, RecentPagesByPath is removed as well. The dependencies concept ensures system consistency and might be enhanced with on-line module repository later.

3. Directories and file names. The rule is: the easier the better. Let's get rid of annoying prefixes and postfixes, e.g.:

admin/admin.plug.inc.php => admin/plug.php
twitter/lang/twitter.nl.lang.php => twitter/lang/nl.php

Now, putting modularization and simplification together, let me show an example file tree:
-------------------------

datas (no changes)
images
	flags
	smilies
js (no changes so far)
lang (core langfiles required by all modules)
	en.php
	nl.php
	ru.php
	...
modules
	admin
		js (some JS files if required)
		lang
			en.php
			nl.php
			...
		tpl (default tpl files that come with a module)
		...
		banlist.php
		bbcode.php
		cache.php
		...
		functions.php
		...
		main.php
		
	adminqv
	chili
	cleaner
	comedit
	forums
	forumstats
	index
	indexpolls
	ipsearch
	markitup
	massmovetopics
	news
	list
	message
	page
	passrecover
	pfs
	plug
	pm
	polls
	recentitems
	rss
	search
	seditio
	statistics
	tags
	whosonline
	users
	
skins
	skin_name
		admin
			banlist.tpl
			bbcode.tpl
			cache.tpl
			...
		forums
			editpost.tpl
			newtopic.tpl
			posts.tpl
			...
		page
			add.tpl
			edit.tpl
			display.tpl
		...
		index.tpl
		list.tpl
		news.tpl
		message.tpl
		(etc., for modules with 1 template)
sql (no changes)
system
	
	common.php
	footer.php
	functions.php
	header.php
	index.html
	mysql.php
	parser.php
	xtemplate.php
admin.php
forums.php
index.php
list.php
message.php
page.php
pfs.php
plug.php
pm.php
polls.php
rc.php
rss.php
users.php

---------------------------
Alternative proposal would be for putting all lang files in lang directory, e.g.:
-----------------------------

lang
	en
		admin.php
		comedit.php
		forums.php
		...
		main.php
		...
	nl
		(same as en)
	ru
		(same as en)
	...

---------------------------
Which is better for langs - I hope translators answer this question for me.

Please post your comments below. We need to decide about this before we start changing structure.

4. Admin part. As Modules concept is unified, so that there is no more core/plugins, it means that admin part needs to be rewritten. I suppose there will be a tree, so that there are root-level modules (formerly known as core), on the second level modules that expand/depend on them, etc. In the UI it could be done as a context menu or desktop-like icons.

Each module will have its own configuration, its own permissions (with more than 1 area) and if admin.php is supplied, it will be run in Admin => Module_name too.