Cotonti / Open Source PHP Content Management FrameworkContent Management Framework

Foren / Cotonti / Core Labs / Archive / Starting modulation


#16 26. Juni 2009, 00:07
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:

  • avatars
  • html (is this used ?)
  • photos
  • thumbs
  • tmp
  • files (replaces users)
  • en
  • nl
  • ...
  • admin
  • index
  • forums
  • pfs
  • pm
  • ...
  • recentpages
  • bdcards
  • cleaner
  • news
  • forumstats
  • ...
  • sed_light
    -   lang
    -   styles
  • ...

Dieser Beitrag wurde von Koradhil (am 26. Juni 2009, 00:27, vor 11 Jahre) bearbeitet
#17 26. Juni 2009, 01:36
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.
May the Source be with you!
#18 26. Juni 2009, 01:41
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.
#19 26. Juni 2009, 01:55
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?
May the Source be with you!
#20 26. Juni 2009, 02:13
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)
#21 26. Juni 2009, 04:26
# 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). - создание сайтов, разработка плагинов и тем для Котонти
#22 26. Juni 2009, 06:59
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.
#23 9. Februar 2010, 02:15
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.
May the Source be with you!
#24 9. Februar 2010, 02:52
I like
Pavel Tkachenko aka Dayver. Гик и веб мастер который делает сайты, увлекается электроникой и очень любит смотреть кино.
О себе: Я злой и страшный серый волк, я в поросятах знааааюююю толк
#25 9. Februar 2010, 03:33
As regards translation, I do not see any obvious problems. - создание сайтов, разработка плагинов и тем для Котонти
#26 9. Februar 2010, 03:45






GOOD idea
#27 10. Februar 2010, 03:39
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/ instead of system/core/forums/ 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.
May the Source be with you!

Dieser Beitrag wurde von Trustmaster (am 31. März 2010, 01:01, vor 11 Jahre) bearbeitet
#28 10. Februar 2010, 05:35
- 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.
... can we help you ...
#29 10. Februar 2010, 13:55
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. - создание сайтов, разработка плагинов и тем для Котонти
#30 10. Februar 2010, 14:05
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:

- 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.
May the Source be with you!

Dieser Beitrag wurde von Trustmaster (am 10. Februar 2010, 14:16, vor 11 Jahre) bearbeitet