Directory structure, naming conventions and stuff

[potfur]

We should define directory structure that will be used in modules/packages/bundles (or whatever name we will use) - what is the name of directory with controllers, models, repositories and stuff. Also should we use always singular or plural?

My proposition is like this:

./src/
    /{module}/
        /Entity/
        /{end}/
            /Controller/
            /Model/
            /Repository/
            /Resource/
            /View/

Where module is the name of ... module. end is frontend/backend/otherend directory. This means that we have a module which supports frontend and backend or just backend functionality.

/Entity/ is a directory for entities, ie. Post, User etc. /Controller/ for controllers for set *end, /Model/ ideally only models should contain logic, but ... we won't have complex logic /Repository/ classes that have access to database /Resource/ all stuff that should be copied from module to public directory ie. images, css, fonts etc. /View/ view templates

[marcotroisi]

Very nice. A few questions/comments:

1. How about we have a module per each entity? So, there would be a module for posts, one for users, etc...
2. Where would the SQLite tables structure for each entity be defined? We need to think of a really really easy way to do that. Let's not forget that this is going to be the structure that people will use to develop plugins/modules, so it's got to be easy overall.

[potfur]

1. Module should be about functionality not about entity. Eg. auth module will be about User entity, but blog module can contain post, tag, comment and comments author - all entities.
2. Every module in its main directory should have bootstrap file containing all ORM models, routes and other configuration.

[marcotroisi]

1. Agreed, very good point.
2. That is what I thought too.

[gerty3000]

@potfur I have question about module's bootstrap file. What exactly this mean? Is it just simple array or something more complex eg class with common interface?

[potfur]

@seclu Simple array - look at current boostrap.php files. Soon I will implement auth module - as example for other modules.

[gerty3000]

@potfur Ok, I understand. I'm not sure that this solution is enough good. I think that good and safe boundary for every module is common interface. In other hand I don't have any strong argument against array :) IMHO interface is just more flexible and programmer friendly.

[fabfuel]

I think I would also prefer a ModuleInterface where we ensure a certain structure. Currently I don't know yet what the bootstrap should do or return :smiley:

[potfur]

Bootstrap is always a configuration array - same as described in Moss config.

[marcotroisi]

I am very much in favour of an interface. I think we should find a way to do that. It does not really matter if Moss natively uses arrays, we can still abstract that to an object if we think it is better. Ideally, I think we should always know what the Module Config will return, and then give that to Moss in the format that it wants it. Moreover, this is the Vox Module bootstrap we are talking about, not Moss's. At any point we might need to add or change stuff in that config, and we should not be too attached to what Moss expects.

[potfur]

Maybe something like this:

interface VoxModuleInterface {
    public function name();
    public function ver();
    public function registerConfigVars(ConfigInterface $config);
    public function registerComponents(ContainerInterface $container);
    public function registerEventListeners(ConfigInterface $dispatcher);
    public function registerRoutes(RouterInterface $router);
}

This is just a rough sketch, probably there will be more registerSomething methods eg. registerModels for DBs.