Skip to main content
Topic: Code reworking: directory structure (Read 13282 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Code reworking: directory structure

I need your input on this.

Issue:
Currently we have /Sources, with 133 files (really), and a subdirectory Sources/lib with 2 external dependencies. While /Themes/default/ has 52 template files, and subdirectories for images, scripts, etc. The 133 files in /Sources are of several kinds:
  • controllers (admin and user actions handlers, i.e. ManageXxx and Profile.php etc) (about 70 files)
  • Subs- files (utility, library files) (31 files)
  • Class- files (6 defined at this time. We will add more, but I expect a maximum of 10-12 for version 1.0 or something)
  • other core files (database, about 9 files without those in Subs-, search classes (I didn't count them above cuz of name), core files like Load.php, Subs.php, Security.php etc.)
I need to reorganize these files, we are removing a few but we are adding more than we remove (at least twice more), as we rework the code... There are more options to do so... Which is more understandable, or your preference, or you see better reasons to, easier to work with?

Option 1: use a /Sources/controllers directory.
  • /Sources/controllers will hold controllers (in time they'd be Admin.controller.php), (about 70 files)
  • Themes/default/ holds templates (our known xxx.template.php), roughly a template file [should] correspond to a controller file (52 files)
  • /Sources/lib = external dependencies (as it is already)
  • /Sources = the rest, library [Subs-xxx], library classes [Class-xxx], etc. (we're left with about 60+ files)
Please see and browse :)
https://github.com/norv/Dialogue/tree/dirs_test1

Sub-option... only admin controllers separated from the rest, i.e.
https://github.com/norv/Dialogue/commit/f19ee9d277534d8ca3ca1b93cd75ab2718bc31f2
Sub-option... only admin, but all related to it, separated as /admin... (controllers + Class-xxx utility + Subs-xxx utility, all admin stuff)

Option 2: use the Sources/lib directory.
  • Library files to Sources/lib (Subs-, Class-, core library, search etc) (aprox. 62 files)
  • the rest, basically the action handlers, what I called controller files, remain in /Sources (aprox. 70 files)
Problem with this, IMHO, is that the external libraries, the 2 we have in /lib currently, are no longer clearly separated. This isn't a good idea, the best practice (and expected by developers and automated build tools alike) is for them to be clearly in some easily distinguishable directory. Many name it /vendor.
Sub-option: move the external libraries to /Sources/vendor.
https://github.com/norv/Dialogue/tree/dirs_test2


Constraint of all options... We have a $sourcedir refered many many times in the files, which is used by people to secure the files that don't need to be in the public web directory. I think it would be easier if at this time, $sourcedir remains exactly that: a single variable to set to another location, outside "public_html" (whatever it's named), where people may move their entire /Sources dir and its subdirs. So I wouldn't "take out" of /Sources any of these dirs ("controllers" or "lib").

Which is better and why?
Last Edit: December 20, 2012, 05:45:55 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Code reworking: directory structure

Reply #1

Option 3: Reduce the number of files. Really.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Code reworking: directory structure

Reply #2

I really don't think that will happen soon (at all). We do where appropriate, but it cannot be done just like that: on the contrary, 4000-lines files is insane. (usually; and those doing everything under the sun and don't forget their mother's shoes, moreso.)

1/
I'll note that the redesign we're doing already removes code, because it removes duplicate code. (by consolidating the duplicate common stuff in library functions). Sometimes it does arrive to the point of removing useless files, yes, but more often than not, it doesn't. (not now, for a 1.0+ version).

2/
The longer-term goal is to redesign the code such that features/functionality become more modular. Which answers the "reduce the number of files" differently: the admin can always remove (or not download and install at all) the modules.

ETA, 3/
Well hey, we cannot have new features without adding new code. 1/ and 2/ exist exactly to address that. Make it possible, with better designed code.
Last Edit: December 21, 2012, 01:20:02 am by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Code reworking: directory structure

Reply #3

Quote from: Antechinus – Option 3: Reduce the number of files. Really.
Yeah ... I don't think we are done adding TBH ... but it will be easier to find where a function is located. Plus feature cat wants to add more :D

I like the idea of the controllers in Sources and then the helpers in Sources/helpers (pick your name) and leave Sources/lib for the things that are not ours ... library functions that we make use of .... Or go even further and bring helps up to the same level as Sources.

The Monkey and I were talking about this a bit, and no matter what we do, we only want to do it once (the dir structure) and then we needs to live with it, so lets make sure we have a structure that makes the most sense going forward

Re: Code reworking: directory structure

Reply #4

Quote from: Spuds – The Monkey and I were talking about this a bit, and no matter what we do, we only want to do it once (the dir structure) and then we needs to live with it, so lets make sure we have a structure that makes the most sense going forward
I don't believe you. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Code reworking: directory structure

Reply #5

LOL ... you can believe that I at least said it  :P
Last Edit: December 21, 2012, 06:43:59 pm by Spuds

Re: Code reworking: directory structure

Reply #6

A quick update for you folks to browse around. Sorry for being on the run at the moment. I will come back on it to eventually discuss some of the aspects involved here. Short story is... Drivers for the solution are: the next two major versions, addons expectations and good practices (please take a look in /Packages/gallery too), and still within constraints (like mentioned in the OP) and in a way, a maximum of compatibility with our current codebase and habits of work... (well where this maximum is lower than the first two concerns :D)

https://github.com/norv/Dialogue/tree/dirs_test4
Last Edit: December 21, 2012, 02:43:48 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Code reworking: directory structure

Reply #7

OK :D... Ema said moar...

Split some modules of the main body: first candidates are imo those with many actions/subactions (those with a menu of their own, admin, mod, profile and pm), and auth, search, attachment, calendar and packages. (I 'made' the first several)
https://github.com/norv/Dialogue/tree/dirs_test5

Please see /Sources... respectively /database and /ext are there too. Oh, and 'the rest' are in /forum... that is, forum module.

What will happen in this case is that many *.subs.php files will be cross-used imho. Which is fine, but then we need a way to locate them immediately, to type easily. Such as, function loadLib ($modulename, $filename = ''), i.e. loadLib ('pm'); will load all .subs and .class in module 'pm' (there's only one :D), or loadLib ('pm', 'PersonalMessage') will load specifically this .subs file.

There is no claim (other than naming patterns and action handling from dispatcher; respectively a few functions like loadModule() as Ema wants or loadLib()) that these modules are anything 'more' than what they were: only functionality is separated in their own subdirs. That is, there's no question of managing them, install/uninstall and so on.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Code reworking: directory structure

Reply #8

Having the various levels to look at really helps, thanks for doing that.

To me the 4th is about as far as I would go,  the 5th really seems excessive to me ... at that point you would begin to wonder where to put things, at least I would.  And no no no need to explain it for me :P  .... its just an IMO.

I'll cruse around a bit more on it ... but just seems when you get as granular as the 5th .... its just to compartmentalized and therefore subject to breaking where we need YAD (yet another directory) to put 2 files.

Last Edit: December 21, 2012, 06:44:59 pm by Spuds

Re: Code reworking: directory structure

Reply #9

You gently caress are crazy. :P

Go for 2 levels max.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Code reworking: directory structure

Reply #10

Adding a few details...

Tweak on dirs_test4 : https://github.com/norv/Dialogue/tree/dirs_test4/Sources
# bring /languages in Sources... (experimental)

So on option #4, we have /Sources with
  • admin (optional)
  • controllers
  • database
  • ext
  • languages
  • lib


Tweak on dirs_test5 : https://github.com/norv/Dialogue/tree/dirs_test5/Sources

# rename, are capitalized names better?
(/database and /ext are not modules, neither is exactly the forum core)


In both cases, (big) addons would be probably be like:
https://github.com/norv/Dialogue/tree/dirs_test5/Packages/Gallery
(pretty much the same structure as a module, no matter if 'taken out' [5] or 'aligned with the rest' [4].)
Last Edit: December 21, 2012, 09:38:23 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Code reworking: directory structure

Reply #11

Still think 5 is over the top  :D

4 looks good to me ... don't mind the admin functions in their own little area, given that the admin area is its own little thing anyway but not sure about another languages directory under there as well.

I like the rename of the files form Subs-Xyz.php to Xyz.subs.php quite a lot, makes finding them a lot easier to me. 

As for the caps on the directories or not ... ummm not sure really ... Maybe caps on our base level and lower for the subs?  Today its a mix of, well everything :P

Re: Code reworking: directory structure

Reply #12

Argggggggggggggggggggghhhhhhhhhhhhh. Just put all languages files in the default/languages directory. Jesus, are you trying to make the whole thing incomprehensible? :P
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Code reworking: directory structure

Reply #13

LOL .. I tend to agree ... but it is a fascinating look in to how disturbed Test Monkeys mind is :P

Re: Code reworking: directory structure

Reply #14

That's what generated the escalation:
Quote(20:43:16) ***emanuele runs
/Admin/
   |- controller.php
   |- subs.php
   |- lang/
   |- english.php
Attachments/
   |- controller.php
   |- subs.php
   |- lang/
   |- english.php

So you know how far I could go. :P

To me it's the same.
It seemed just a bit odd that if I'm working on Admin-something I have look into a directory for the controller and another one for the "subs".

BTW I think the renaming of Subs-something to something-subs. I was thinking to propose it myself because that way the related files are closer and the alphabetic sorting allows to find things in much less time. :D
Bugs creator.
Features destroyer.
Template killer.