cotonti.com : Starting modulation

tensh

Ср, 10 Лют 2010 18:29:22 -0000

I wonder how the end of this process will look like I can't imagine creating a whole module yet, it would involve creating a file like page.php and a module structure in /modules directory... interesting.

Trustmaster

Ср, 10 Лют 2010 14:05:47 -0000

http://www.cotonti.com/articles/org/technical_concepts:
The exact areas of the site are provided by modules. A Module is a root-level script which includes the core libraries and most often consists of several parts united with the same goal: implement the exact kind of functionality such as Forums, Private Messages, Pages, Polls, Galleries and so on.

Modules are quite large and they would not be flexible enough if there was no such a thing as plug-ins. Plugins are smaller packages consisting of parts which can hook into exact parts of modules and extend them. And there are enough hooks to get almost any behavior you need without hacking the core or rewriting the modules themselves. Plugins also can have standalone, popup and ajax parts which are often needed too.

As for langfile names, prefixes can be easily put back if it's more comfortable for translators.

Added 10 minutes later:

pieter:
- each module can have its own tpl's. Can they be different for each skin?
I mean for skin X I want a TPL like this, but for skin Y a different? Does it work like the tpls works for plugins at the moment? First look in the skinfolder/plugins and if it is not present there looking in the plugin folder.

Yes, exactly. It looks for them in skin folder first, then in the default skin folder and falls back to module tpl folder if none were found in skins.

Kort

Ср, 10 Лют 2010 13:55:03 -0000

I think we've discussed the issue of meaningful lang-file names: admin.en.lang.php instead of en.lang.php. This would indeed make the work simple & easy.

pieter

Ср, 10 Лют 2010 05:35:33 -0000

- What is the difference between modules and plugins?

- each module can have its own tpl's. Can they be different for each skin?
I mean for skin X I want a TPL like this, but for skin Y a different? Does it work like the tpls works for plugins at the moment? First look in the skinfolder/plugins and if it is not present there looking in the plugin folder.

Trustmaster

Ср, 10 Лют 2010 03:39:28 -0000

Well, the best way to learn what I've done to directory structure is browsing the new trunk tree

The most important changes in Modularization Stage One are:

Modules now reside in modules directory rather than system/core
Every module can have a full set of necessary files in its folder: lang, tpl, img, etc. It can have its own functions.php and resources.php file. But all these are optional, you are not forced to use them all.
Names of include files are shortened, the duplicate part is removed. So, now it is modules/forums/editpost.inc.php instead of system/core/forums/forums.editpost.inc.php. Langfile names are also shortened, so English forums langfile is modules/forums/lang/en.lang.php
There is a lang folder in root with subfolders by language. These are core langfiles (main, countries, skin) which are shared between all modules.
The APIs have been split into files too. It's a bit pity but functions.php does not contain many thousands of lines with all the functions you would need ever. It contains very basic functions and functions used everywhere. Logically separate and consistent APIs now have their own files located in system folder: cache, debug, email, extrafields, tags, uploads. The number of APIs will grow and there will be less dependencies (low coupling), so that Cotonti becomes more like a CMF.
The uncomfortable thing about APIs is that you have to require them explicitly. So, if you need file uploading functions in your module or plugin, then you'll have to require them:
```
require_once sed_incfile('uploads');
```
Currently the number of explicit includes has grown, some implicit includes (like xtemplate.php) have become explicit. It results into more code but less hidden dependencies and unused code overhead. Probably, a better way saving you time coding will be presented later.
Admin module has its own default skin. So you don't need to implement admin part in your skin if you don't really want to. Actually, every module now has support for its default template (useful for third-party modules shipped with default templates), but admin module has its own header/footer.

The Modularization Stage Two means implementing APIs for automated module and plugin management. So that you can drop the modules in as easy as plugins.

Gökhan YILDIZ

Вт, 09 Лют 2010 03:45:15 -0000

skins/skinname/forums/tpl
skins/skinname/forums/tpl/custom
skins/skinname/forums/plugins

skins/skinname/main/tpl
skins/skinname/main/tpl/custom
skins/skinname/main/plugins

skins/skinname/page/tpl
skins/skinname/page/tpl/custom
skins/skinname/page/plugins

skins/skinname/list/tpl
skins/skinname/main/tpl/custom
skins/skinname/list/plugins

skins/skinname/css
skins/skinname/css/plugins
skins/skinname/css/forums

skins/skinname/js
skins/skinname/js/plugins

GOOD idea

Kort

Вт, 09 Лют 2010 03:33:15 -0000

As regards translation, I do not see any obvious problems.

Dayver

Вт, 09 Лют 2010 02:52:58 -0000

I like

Trustmaster

Вт, 09 Лют 2010 02:15:20 -0000

There is a possibility of applying modularization on Siena. The directory/file structure is very similar to what was suggested by Koradhil above. Core scripts will be moved to modules, each module will have its own include files, language files, functions, resources and default templates (optional), etc. System folder will contain the very Core and various APIs. Plugins will be backwards compatible. Language files are split into more files.

Please tell if you like or dislike the idea of applying modularization in Siena.

GHengeveld

Пт, 26 Чер 2009 06:59:34 -0000

I agree with Kort, we don't really want just 'en.php'. It's really no problem having 'something.en.php' if it helps to keep things clear. Same goes for variable names: it's better to have a long name which is descriptive, than a short one which makes no sense. I'd rather use $thumbnailWidth than $th_x for example (or $mode instead of $m). This is something to be looked at throughout the core code in my opinion.

Kort

Пт, 26 Чер 2009 04:26:34 -0000

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

In my opinion, it would be better to keep "parent" names [for lang-files] to enable easy & recognizable file operations / updates. Unlike "depersonalized" names line en.php, unique names are searcheable and allow files to be stored in one folder (sometimes you really need that).

Kilandor

Пт, 26 Чер 2009 02:13:39 -0000

If plugin files start getting split into multiple area's that will become a pain in the ass.

Plugins should be considered there own thing. like they are now, as they may make various tweaks to existing things, or be completely standalone on their own.

Modules should be considered the "core" but with such a design I can say take another PFS, or Forum module and throw it in, in replace of the default so it should still work seamlessly without any major coding changes. (So major things for each "module" need to have exentsive api system)

Trustmaster

Пт, 26 Чер 2009 01:55:03 -0000

OK, what to do with things that have both standalone and hooking parts like Attachments or UserGal? Split into Module + Plugin? Leave as Plugin with standalone support?

Kilandor

Пт, 26 Чер 2009 01:41:19 -0000

Modules != Plugins

Plugins != Modules

Modules would be a basicly complte dropin package to completely replace a core system.

Plugins, as always custom made, small modifications, or individual systems.

Trustmaster

Пт, 26 Чер 2009 01:36:26 -0000

I agree that having them separate would be easier to keep things in order. I just want to be sure there is no duplicate code/functionality between them. In this case some "packages" would have both a Module and a Plugin in them.

GHengeveld

Пт, 26 Чер 2009 00:07:23 -0000

I think your proposal is very good. The lang is good as well. The alternative is not so good imo, because it would require you to remove a separate file from /lang if you remove a plugin, instead of just removing the entire plugin folder. Also it will make installing the plugin slightly easier, as you can just upload a single folder to the plugins/modules dir and you're good to go.

Personally though, I feel there should be a difference between modules and plugins. It will not only make the transition less complicated (because you can keep the current plugins dir and you only have to move /system/core to /modules), but you will also keep the modules dir from cluttering. I personally think the line between modules and plugins should be drawn where there is a need for standalone page. For example, forums is a module because it has its own page(s), while recentitems is a plugin because it is only displayed as part of a bigger page (usually header or index), and thus does not use a standalone page.

I suggest the following structure:

datas

avatars
html (is this used ?)
photos
thumbs
tmp
files (replaces users)

lang

modules

admin
index
forums
pfs
pm
...

plugins

recentpages
bdcards
cleaner
news
forumstats
...

skins

sed_light
- lang
- styles
...

system

Trustmaster

Пт, 01 Травень 2009 00:52:49 -0000

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.

tensh

Thu, 30 Кві 2009 16:36:01 -0000

What's wrong with the current structure of folders? o_O?

I agree that functions can be split, but why change the position of lang,skin folders as well as skin folder structure?

Personally I don't like surfing through numerous folders to find something. You can check how it feels when you install eZ Publish. Design folders are very good, why creating folders for tpl files if their names are already telling you which part they're assigned to? Different folder names are usually used when file names are the same, like:

skin/forums/view.tpl
skin/forums/edit.tpl
skin/page/view.tpl ...etc, etc.

I don't see any point in this. Not to mention we don't have thousands of tpl files...

GHengeveld

Нд, 15 Лют 2009 08:35:53 -0000

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.

esclkm

Нд, 15 Лют 2009 08:30:06 -0000

some disagree:
/core (lang must be in core)
/datas
/docs
/images
/js
/lang
/modules (I think JS must be powerful module)
/plugins
/skins
/system

Dayver

Нд, 15 Лют 2009 07:00:00 -0000

not bad

but in root folder core == system

GHengeveld

Нд, 15 Лют 2009 06:43:59 -0000

I think it would be best to have a skins folder structure that matches the folder structure of controller (core/modules) files.

So the root looks like:
/core
/datas
/docs
/images
/js
/lang
/modules
/plugins
/skins
/system

And a skin folder looks like:
/core
/modules
/plugins

Dayver

Нд, 15 Лют 2009 06:28:45 -0000

I think all the tpl files must be contained in the skins folder skins/your_skin/... it is convenient to all (optimal)
no matter what the structure
skins/your_skin/modules/...
or
skins/your_skin/admin/...
or
skins/your_skin/plug/...
or
skins/your_skin/...

this is indeed correct!

GHengeveld

Нд, 15 Лют 2009 06:25:47 -0000

TPL in a systems folder doesn't make any sense at all, and it also makes it harder to install and use multiple skins.

I do agree with OC that we should start separating more functionalities. I think we should take out some stuff from /system/core and put them in /modules. For instance, forums, pfs, pm, polls and view can be removed from the core and put into /modules.
These modules should be the same as stuff inside system/core as far as technical implementation and possibilities go, so they are not like plugins that require hooks.

This is actually not something I came up with, but is described here.

oc

Нд, 15 Лют 2009 06:20:10 -0000

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/

Dayver

Нд, 15 Лют 2009 06:11:54 -0000

No, no, put TPL files in a folder system that is a bad idea

esclkm

Нд, 15 Лют 2009 06:08:52 -0000

I agree with oc at all!
core/forums/design - bad idea
core/forums/tpl -(like plugins) GOOD idea

Lets begin separation function file into special parts - functions for forums for pages etc. AND in functions.php - only common for al core functions

Dayver

Нд, 15 Лют 2009 06:05:36 -0000

core/forums/design - bad idea
skins/sed-light/forums or skins/sed-light/admin - very good

oc

Нд, 15 Лют 2009 05:59:39 -0000

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.

GHengeveld

Нд, 15 Лют 2009 05:50:15 -0000

I agree tpl files could be grouped in folders to keep things organized. Splitting up functions.php doesn't sound like a good idea though, because many functions are used in multiple parts of the site.

oc

Нд, 15 Лют 2009 05:36:15 -0000

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