This is my first question here. :)
I am working on a little php framework and started to think of ways to re-use the same code between multiple projects. Right now with this framework it is possible to make multiple application directories for different projects and use the same core - similar of what codeigniter 2 does.
The question about code reuse raised at work when I needed to make a website that is quite different from existing one, but would still use classes from it.
My first two ideas was either use some kind of a global "models" directory where to place files shared between multiple projects (and add option to framework to load them), or to add a possibility to load these "models" from other project(s).
I thought maybe somebody else have some better ideas and wanted to know other developer thoughts on the subject in general.
As an example this could be the current directory structure:
live/ - live site
config/
controllers/
helpers/
models/
public/
views/
admin/ - administration (same structure as "live/")
system/ - framework core
Well I don't think loading models or other classes directly from another project is a good idea. If two or more projects share the same classes, they should be located somewhere outside of both projects. This is the situation where the codeigniter packages comes in handy. It allows to have separate folder for all of your libraries, models etc. and load them in any codeigniter project very easily. Take a look at the official documentation for more details.
Related
Essentially, I'm looking to have a PHP development workflow that needs to be modular, but using a Single Page Application technology.
I understand it is recommended to separate the back-end from the front-end. Develop them separately. But is there a way to group all related code into one module (or folder), meaning all backend code with its own views presentation inside the same folder?
It's like MVC, but the "V" contains fragments of vuejs (or angular) files, which extends from a master file somewhere in your project.
For example
Assume we are building a modular CMS, where you can upload "plugins" (really, PHP modules), extending the CMS' functionality:
-project[root-folder]
----core[folder] # contains all infrastracture code, api routes, master view file, magic, etc.
----modules[folder] # uploadable modules goes here
--------User[folder] # sample module; follows the MVC pattern
------------Controllers[folder] # contains files, e.g. UserController.php
------------Models[folder] # contains User.php
------------views[folder] # where vue components is housed
----------------users/index.php # contains vue code
----------------users/create.php # etc...
----------------users/js/user.js
----------------users/css/user.css
--------Blog[folder] # another module
----index.php # the master view or just the bootstrap file
----gulpfile.js
Then inside the core/ folder, there is a master layout that binds all views together.
Will a folder structure like this be viable?
Obvious problem there is you can't use .vue files (as that would mean, every time you upload a new module, you need to run gulp or re-compile).
Hoping for your feedback. Thanks.
This question will strike a lot of folk as bizarre and twisted. That's the reaction I got when I asked it in the context of .net mvc. I'm with you 100%.
I'm too new to js frontend development (and too ignorant of PHP) to have much advice. It's going to be tricky. Ajax calls to PHP code will need to go to paths below the src directory. But then you want to stop your frontend resources being served from these same paths. Both PHP and gulp will want to use file paths for urls, but at least for Gulp this can be controlled.
I'll follow this with interest. My ambition is to keep in the same folder things you're likely to want to delete together, and for those things to be able to call each other with short, relative paths. The ideal would be to be able to specify the module route independently of the path on disk, and to have this route work for both frontend bundled resources and services. Good luck !
I came across this question whilst searching for an approach for exactly the same problem. I'm building a "platform" rather than an application with a plugin system along the lines of Wordpress. I have the additional issue of the platform itself being a 'multitenancy' environment, too - so any plugins cannot interfere with the core "Dashboard" that holds these things together.
So; posting for a few reasons, two years on...
Did you get anywhere and would you care to share any thoughts?
I came across a quite extensive article for PHP Phalcon that has certainly given me a few ideas. Sharing incase it helps you/others:
https://blog.antsand.com/singlepost/index/5619/How-to-integrate-php-(Phalcon)-and-Vue.js-components
There's a line buried in the series that says "As a rule of thumb. Structure your code, based on the application and NOT on the programming language and frameworks." I'm not sure how wise or not this is, but it certainly gave me something to crack on with.
So right now, I have a module folder a bit like:
/mymodule
/Controller
/Model/
/Template
thing.vue
/Assets
/js
/css
MyModule.php
Assets are handled via a framework route (i.e, /assets/{path:.*} )
Templates are handled via the (PHP) module install script to make sure webpack knows where they live.
Still at proof-of-concept stage but rightly or wrongly, it seems to work well enough!
I'm working on a PHP project with Laravel 5 and I'm thinking of setting up a different folder structure for it.
The standard Laravel folder structure is something like this:
/app
/commands
/Http
/Controllers
/Middleware
Kernel.php
routes.php
/Providers
Model.php
/config
/resources
etc...
However, when the project grows larger and you have a lot of Controllers/Repositories/Models and such. This structure is gonna break.
For example: it's not very easy to find a bug in your admin panel if you have to dig through your routes, find which controller is responsible, find that controller amongst a large set of controllers, find out what that does, find out other possibly responsible classes in other large folders, and so on. In short: it's a mess.
I've been looking at ways to break the structure into modules. I've come up with a way to do it, but I'm not sure if it's a good way.
I would make a folder each functionality and put all the related code together. For example:
/app
/Admin
/Controllers
/Requests
/Models
routes.php
/Products
/Controllers
/Requests
/Models
routes.php
etc. (you get the point)
Instead of initializing 1 router from the standard RouteServiceProvider.php, I would have to write a ServiceProvider for each module and start all individual routes from there. So in this case I would have an AdminServiceProvider and a ProductServiceProvider which each require the routes.php file in their own subdirectory (and with that their own controller namespace).
This seems to solve my case for now, but I'm wondering if I'm gonna run into trouble with this setup. All the examples I can find on the web just stick to the standard structure. Can anyone tell me if this is a decent way to do it? Or does anyone have an alternate way of doing this?
This is a good way you proposed but there is no need to do it on your own. At the moment I'm working on a L5 project that uses modules - each of them have directories for repositories, models, own route file etc. I'm using Caffeinated module for that
I also believe the structure looks good. I would also add on an additional, core or base folder which will contain base classes and reusable componets, to ensure you do not have duplications of code in the separate "modules"
You can also checkout this interesting presentation at a Laracon, September 2014: Laracon 2014: Dayle Rees - Breaking
The Mold
Also have a look at the source for October CMS and Doptor
CMS(claims to be moduler), you may glean a thing or two. (Have
used neither, by the way).
Otherwise, do what I did and Google Opensource Laravel projects.
You get good insight from them. Especially those that a featured or
are organised, with growing communities.
At this moment, my framework's directory structure looks like this:
framework/
libraries/
autoload/
autoload.class.php
resource.namespaces.php
router/
tests/
router.test.php
router.class.php
resource.routes.php
configuration/
framework.configuration.php
router.configuration.php
controllers/
index.controller.php
models/
index.model.php
views/
default/
index/
index.view.php
header.view.php
footer.view.php
assets/
css/
javascript/
images/
index.php
When my framework was smaller, it was a lot cleaner. I have give a look at other popular frameworks. They have two main folders:
framework/
app/
web/
Actually, this structure is very clean and nice because we separate the front-end and the back-end. But I wonder what should I put in each of these.
Logically, libraries folder should be inside the app folder, but it is not really a part of the application. For me, an application has models, controller and views. I think libraries should be put outside. Where should I put my libraries?
I has a lot of PHPUnit tests in my libraries. Should I add a folder named tests inside each library, or should I put it inside/outside the app folder?
If I want to implement a template feature, where I could choose which template I want to use for my website, how could I organise it? Every template has differents elements, so header.view.php will not be the same, etc. Now, I'm creating a folder in views which is the template folder. But I think it is a bad idea, 'cause now, for every template I must recreate all the views.
In a lot of applications, there is a vendor folder that contains all the main classes. Is this the same as my libraries folder? Does it have the same role?
I also have some 'resources' files (eg.: resources.routes.php). They are used to add some routes/namespaces. It's a bit like a configuration file. Should I create another direcotry for these files, or put them inside the class which they refers to?
I'll try to cover all your questions.
The vendors folder that you see in many apps is from composer. In that folder are all the dependencies of your application/framework (often libraries from other people).
Composer allows you to pull in some good components for your framework so that you don't have to write everything from scratch. Say for example I want to use FastRoute because it is much better than any router I am capable of writing myself. So I just add the following to my composer.json, run composer update and I can use it in my framework.
{
"require": {
"nikic/fast-route": "dev-master"
}
}
You can also use composer to autoload your classes so that you don't have to write your own autoloader (and cache that for production).
I really dislike your current file names. adding .class to a filename makes absolutely no sense to me. The dots also just complicate Autoloading. I recommend you have a look at PSR-0 for some inspiration on how to handle file names/namespaces (This is supported by the composer autoloader).
For the tests you could create a Tests folder in the root folder of your project and in there recreate the directory structure of your project and add the test classes in the matching folders. You can also put your mock objects in there. This makes it easy to just run tests for a certain part of your application.
I also recommend that you move your application out of your public folder and instead have a public folder with only an index.php and your assets. That index.php does nothing other than requiring your front controller that bootstraps your app. Doing it that way adds another layer of security if for some reason your webserver stops processing PHP. Otherwise a visitor would be able to see your whole source code.
To get some inspiration for your folder structure questions, I recommend that you have a look at how other people solved this issue. Arya and PitchBlade would be a good starting point because they are way smaller than a framework like symfony.
I hope this helps. In the future I recommend that you split up your questions into different SO questions, that makes answering easier and you will get better answers because people who know the answer to one of your questions don't also have to answer all of them.
I am in the process of learning Kohana 3. Just curious: some Kohana 3 projects I have looked at, like Kohanut CMS are implemented as one big module and located in /modules instead of /application (which is empty). Why is that? Only to make it easier to drag just one folder if you upgrade Kohana later?
All depends what you are doing. I sometimes split different sections of my application into multiple modules. Usually its just for organization or if you want to use that piece on another application.
I've been trying a bunch of different directory structures for my PHP MVC framework. While doing this, I thought of a few reasons to separate different parts of the application from each other.
For instance, let's say this is my current structure:
- index.php
- private/
- application/
- ... (MVC stuff. Irrelevant I think...)
- config/
- config.php
- framework/
- bootstrap.php
- includes/
- library/
- ... (Framework classes)
- libraries/
- Zend/
- PEAR/
- public/
- css/
- images/
The way I have it, I can update the framework simply by overwriting the /private/framework/ directory, which won't affect the user's framework configuration in /private/config/, or the 3rd party libraries in /private/libraries/.
The /index.php file is used almost purely to load the /private/framework/bootstrap.php file, which will mean updating the /private/framework/ directory will also update the main bootstrapping file (Saving me from having to update the /index.php file, which will stay as is, as there's not much at all in it).
Also, the application is separate from everything to do with the framework too, so the user can switch/change/update their applications when needed without having to worry about other directories.
Am I on the right track here with regards to separating the directories from one another to make them easier to update?
I've seen in some frameworks that they have both their /private/libraries/ and /private/application/ directories inside their framework directory... but this seems to me like it would be hard to update to a newer version of the framework if needed. Or am I thinking about it the wrong way?
You can see my previous dir structure here if you're interested. My new one is a little different (hopefully better...), as is my question, so I thought it warranted the posting of a new question.
It's not as small of a question as I would have hoped, but ah well! ;)
Thanks in advance =)
I would suggest separating framework code from application code. The framework should be under one top-level directory and the application under a different one.
Actually... I suggest you look at the directory structure used by CakePHP.