GHengeveld |
|
---|---|
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
|
|
This post was edited by Koradhil (2009-06-26 00:27, 15 years ago) |
Trustmaster |
|
---|---|
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!
|
Kilandor |
|
---|---|
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 |
|
---|---|
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!
|
Kilandor |
|
---|---|
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) |
Kort |
|
---|---|
# 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). SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
GHengeveld |
|
---|---|
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.
|
Trustmaster |
|
---|---|
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!
|
Dayver |
|
---|---|
I like
Pavlo Tkachenko aka Dayver
|
Kort |
|
---|---|
As regards translation, I do not see any obvious problems.
SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
Gökhan YILDIZ |
|
---|---|
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 Gökhan YILDIZ
|
Trustmaster |
|
---|---|
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:
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!
|
|
This post was edited by Trustmaster (2010-03-31 01:01, 14 years ago) |
pieter |
|
---|---|
- 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 ...
|
Kort |
|
---|---|
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.
SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
Trustmaster |
|
---|---|
http://www.cotonti.com/articles/org/technical_concepts: As for langfile names, prefixes can be easily put back if it's more comfortable for translators. Added 10 minutes later: pieter: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!
|
|
This post was edited by Trustmaster (2010-02-10 14:16, 15 years ago) |