Cotonti / Open Source PHP Content Management FrameworkContent Management Framework

Forums / Cotonti / Core Labs / Archive / Starting modulation

123>>>

oc
#1 2009-02-15 05:36
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
GHengeveld
#2 2009-02-15 05:50
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
#3 2009-02-15 05:59
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.
Dayver
#4 2009-02-15 06:05
core/forums/design - bad idea
skins/sed-light/forums or skins/sed-light/admin - very good
Pavel Tkachenko aka Dayver. Гик и веб мастер который делает сайты, увлекается электроникой и очень любит смотреть кино.
О себе: Я злой и страшный серый волк, я в поросятах знааааюююю толк
esclkm
#5 2009-02-15 06:08
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
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Dayver
#6 2009-02-15 06:11
No, no, put TPL files in a folder system that is a bad idea
Pavel Tkachenko aka Dayver. Гик и веб мастер который делает сайты, увлекается электроникой и очень любит смотреть кино.
О себе: Я злой и страшный серый волк, я в поросятах знааааюююю толк

Dit bericht is bewerkt door Dayver (2009-02-15 06:20, 11 jaren ago)
oc
#7 2009-02-15 06:20
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/
GHengeveld
#8 2009-02-15 06:25
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.
Dayver
#9 2009-02-15 06:28
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!
Pavel Tkachenko aka Dayver. Гик и веб мастер который делает сайты, увлекается электроникой и очень любит смотреть кино.
О себе: Я злой и страшный серый волк, я в поросятах знааааюююю толк
GHengeveld
#10 2009-02-15 06:43
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
#11 2009-02-15 07:00
not bad

but in root folder core == system
Pavel Tkachenko aka Dayver. Гик и веб мастер который делает сайты, увлекается электроникой и очень любит смотреть кино.
О себе: Я злой и страшный серый волк, я в поросятах знааааюююю толк
esclkm
#12 2009-02-15 08:30
some disagree:
/core (lang must be in core)
/datas
/docs
/images
/js
/lang
/modules (I think JS must be powerful module)
/plugins
/skins
/system
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
GHengeveld
#13 2009-02-15 08:35
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.

Dit bericht is bewerkt door Koradhil (2009-02-15 08:43, 11 jaren ago)
tensh
#14 2009-04-30 16:36
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...
Trustmaster
#15 2009-05-01 00:52
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.
May the Source be with you!

Dit bericht is bewerkt door Trustmaster (2009-06-25 23:19, 10 jaren ago)

123>>>