Code tree structure

[ferdis]

The current layout of files is a bit weird to me. I cannot grasp why Swiftlet choose this specific tree structure it may have been due to some external concerns for them though.

My concerns:

1. Library is in a public ally accessible place. This isn't always a bad thing, but it's not always a good thing when independent library components are executed by will.While programming, we tend to avoid "including" something when it's not needed. By having users possibly execute components manually, it can cause some errors or warning.
2. The library folder is not clearly defined, Again, this is trivial but I would like to have a structure similar to ezRPG(reword).
3. There isn't a default manner in which new files are created, This could be solved by creating a Wiki page detailing this. We would also benefit from it when plugin/module developers begin to improve and extend core functionality. A simple method which I always use is to create a directory with the name of the class I'm extending. Much like we have now, but a little more organized.
4. Views are in a somewhat irrational place. Again. trivial, but still "unusual".

I have a few ideas of how these points cold be improved, but I'll let you guys weigh in on the conversation first.

[uaktags]

Well I myself liked the structure of ezRPG Rework/1.x as well because everything just seemed like it was in it's place. Lib folder was for all library and core functionality files Templates was for all views Static was for all view dependent static files (js/images/etc) etc etc

A basic change of structure like this would be great imo as it'll be a familiar structure for our past developers to pick up on and it will be simple to understand for future developers of the project.

I think swiftlet chose it's route due to a complete separation of frontend files (views) and backend files (controllers/models/etc), so that the base structure could be given to a team, but that's just a guess.

[ghost]

app/ ...models/ ...modules/ ...templates/ ...lib/ ...hooks/ (Not sure why these are called plugins???) ..bootstrap.php

public/ css js img index.php .htaccess

My suggestion. Comments?

[uaktags]

I like it, I still prefer a static folder that IMG/js/ and CSS reside, but I can still dig it. Another thought, if/when we support individual themes that could be dropped in, would it reside in the IMG, js, and CSS folders or go in a separate folder structured per each theme. On May 20, 2013 3:30 PM, "alex857" notifications@github.com wrote:

app/ ...models/ ...controllers/ ...templates/ ...lib/ ...hooks (Not sure why these are called plugins???) ..bootstrap.php

public/ css js img index.php .htaccess

My suggestion. Comments?

— Reply to this email directly or view it on GitHubhttps://github.com/uaktags/Rework-Revisited/issues/7#issuecomment-18167307 .

[ferdis]

Each individual template could have its assets contained within its own directory, much like Wordpress. I like such a setup, though, client-side libraries will potentially be duplicated.

snip

[uaktags]

One idea, and thank you for mentioning Wordpress as they do it so well (i believe), that I'd like to somehow implement for templates is a check on templates in both the module and the templates folder.

For instance, how it's viewed in WP, is plugins (modules) have their own templates that are shipped with the plugin. A large number of the plugin community though, builds a check against the user's installed Template folder for a template that relates to their plugin, if it's found it loads up that template file and ignores the one in the plugin folder that shipped with the plugin, if it's not found then it defaults to the template file.

Now this functionality in itself could be left up to the developers to decide on how they want to implement if we don't want to create it right off in a function, but I think a folder structure as follows would better suit, though further pollutes the directory a bit more.

../templates
../../themes/
../../../theme_name/*
../../modules/
../../../module_name/*

This way, all developers are expected and encouraged to develop with the vanilla design in mind, it's up to game owners to edit their module's themes to match their own. Since upgrading/reinstalling/etc a module would mean a rewrite over any edits to that module folder, having the site-owners put their modified module-templates in the theme folder under their installed theme would save these changes.

[JakeBooher]

IMO for themes it would make sense to have something like

../themes ../../theme_name ../../../images ../../../templates ../../../css ../../../js

just to keep all theme files in a centrally located place instead of having them spread out like ../images ../../images/themes ../../images/themes/theme_name ../templates ../../templates/themes ../../templates/themes/theme_name etc. Now if you remove a theme instead of searching through many directories to remove the files you simply delete a single directory and you're ready to go

[ferdis]

My previous reply is scrambled, so I'll post it again..

I would suggest: 

./templates
./templates/default
./templates/default/assets
./public
./public/index.php
./public/images
./public/js
./public/css

The public folder would contain base CSS classes and library files.

I don't think we need to differentiate between themes and templates as long as we provide the functionality for multiple "themes". A module is an independent functionality that is added to the system. I would suggest that we let them have their own space somewhere. The client-side libraries like jQuery/Mootools/Dojo would have their place in ./public/js/lib/ext/jquery. I followed a similar design to PHP's namespacing when compiling JavaScript files on the rework.

./js
./js/lib
./js/lib/ext - external libraries, not created by us
./lib/lib/ext/*/plugin/* - plugins that depend on the library

./js/module 
./js/module/xxx/* - a dedicated directory for the module
-- OR if we move module files to directories --
./modules/xxx/assets/* - a module's dedicated space for CSS, images and JavaScripts.

./css
 ./css/ext
./css/ext/bootstrap

[uaktags]

Just to be clear about your remark of differentiate between themes and templates, you're talking about the proposed ./themes/theme_name/templates/ and my proposal for the custom-edited Module-template (Bank for instance). If so, i believe this is the best place for their own space somewhere. The user edited template for a module is going to relate to the theme at hand, rather than the anything else. Since we're editing a module's template to match our theme, i believe it only makes sense to include it in the theme itself. At the very least, I believe it should be outside of the individual module directory itself for the reasons I mentioned originally.

As per the public/js/lib/ext/, I like and agree As per the modules/xxx/assets/ I like that method better than the ./js/module/xxx/* idea.

so just to kinda gather our thoughts together.

ezrpg/
..models/
..modules/
..modules/module_name/
..modules/module_name/assets/*
..templates/
..templates/theme_name/ (default being the one distributed with every ezRPG)
..templates/theme_name/assets/*
..templates/theme_name/template/* (being debated - where user-edited module-views go)
..lib/
..hooks/ (plugins?)

public/
..img/
..js/
..js/lib/
..js/lib/library_name/*
..css/
..css/ext/*

[ghost]

I'd rather call the 'ezrpg' directory app because it would make more sense if we namespace modules, models etc.

namespace App\Module vs namespace ezRPG\Module.

As well as the core library files are under the ezRPG namespace, do I make any sense?

[ghost]

What should templates/theme_name/template/ contain? I understand the assets folder, but not this one.

[uaktags]

that's for the user edited Module-views where a game designer can safely put changes to a module's view file if they need to alter it to fit their theme.

The idea behind this is developers are expected to code and design modules against the vanilla (un-touched) version of ezRPG that we create. The theme that all modules will be coded for is the "default" theme we issue. Now say that you are a game-owner, like that Maximus guy on ezrpgproject who has a theme that we'll call "medieval". The Bank module may have a different layout/css that breaks "medieval"s theme layout. So, depending if module developers (which I believe should be stated as a best practice) include the ability to look in the active theme's folder (medieval) for ./templates/medieval/template/bank.tpl, then it can load that one.

The practice involves a game owner/designer to copy the base template from the module's structure, edit it to fit it's theme's needs, and place it in this location. Now if bank is upgraded at a later point, the changes wont be lost, they'll just have to be amended with the updated version.

so to shortly and quickly answer your question, it'll contain the view file for that template that needs to be altered to fit the theme.

[ghost]

So it is technically just a cascading file system we're talking about?

[uaktags]

sure