Re: Code reworking: directory structure Reply #15 – December 23, 2012, 06:05:19 am The main difference between the two is separation per responsibility first (#4) and separation per feature/functionality first (#5). Well in reality they both exist, the difference is how.Quick summary:Option #4 it groups per responsibility (controller/subs/templates/languages, with tweaks but mainly this way), and that's the definite way forward, for the next two major versions. There's a lot of work to do for it to be even true. the area/feature/'module' are distinguished by naming pattern. i.e. Karma., Profile. (and further Profile.History, Profile.Info, etc.), within the core it doesn't separate first per 'module'/area, but first per responsibility, per role, and only second, per area/functionality. [big] addons or modules have an example to take (and they will). (they're modules, and within, they separate per responsibility). there is a correspondence kept (in a measure) between the components... .controller <-> .template should be very good mapping, mostly with <-> .language too... with some exceptions. For .subs it's a bit different, there is some, but they are driven by a different need.there is and there will be an impedance mismatch between the user interface [to which controller/template map], and the entities, the objects we work with [boards, topics, etc, which is what .subs mostly "follow"]. (i.e. manage boards, boardindex, notifications or read/unread for boards, messageindex, they all deal with "boards" (and may use Boards.subs for their work.)the library of .subs is not and can never be fully per feature/functionality/user interface-available functionality, but it serves them all (/lib, as it is in option #4). It's loosely the 'M' for 'model', and model doesn't obey to them interface rulez. core features (I didn't mention this (sorry)), are also candidates for addons/modules. I'll come back on this. We separate them and use (of course) naming patterns and the associated redesign as necessary for them, aka Calendar, Karma [.controller, .template, etc]I admit... I see other considerents too... The separation per responsibility (if we make it the best) will allow us to look into distributions for Debian or other Linux systems easily... This is also a target for me (still unlikely for first version, we'll see, but as soon as possible).