I am currently planning on a pretty big project that would be split in 4 modules.
Core module (default) - manage ACL, Auth and relations between other modules
Sections - Will separate the differents section of the application and will act as a timeline / progress bar (Locked and unlocked sections based on progress)
CMS - Will provide global content and section specific content
Exams
For those module I will have to develop a back end to edit content/right and so on. What would be the best way to create these?
For now I see two options (there might be more) :
Build the frontend with modules and controller and create a controller within the module with an admin_ prefix
Create an other module for each module, like : core, core_admin, sections, sections_admin, etc.
This depends on how loosely coupled you want to make your modules.
If the modules themselves are never going to move between projects, an admin module might be the simplest solution. The downside to this is that the admin module will be tightly coupled with the other modules. This is the most logical approach from your description.
If you want to keep them loosely coupled, creating separate modules as you mentioned is probably your best route.
Alternatively, if there is not a whole lot to manage, you could always simply create an AdminController in each module and have individual actions for all the various admin tasks. This would get messy as the project grows though.
With any of the loosely coupled choices, you may want to look at using the Zend Regex Router so you can provide a more consistent route to your admin interface.
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:
An implementation of a model (based on doctrine2)
RBAC for the model, including user, group, role models
A xml-based templating engine for ajax backend interfaces
(you name it) ...
Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:
As modules
We include the necessary functions as separate modules into the modules folder.
Pro:
We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
We can provide real functionality (like the user administration) out of the box
We have a bootstrap to set up autoloading and doctrine etc.
Con:
Bad place? Interferes with the users project
A little harder to share between projects (git submodules instead of classpath)
In the library folder
We put it in the library folder and point the classpath to it.
Pro:
Clean solution
Sharing across projects
Con:
Bootstrap has to be explicitly called
No direct routing or actions - everything has to be proxied through the concrete project
So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?
I think you should use both approaches.
When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)
When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.
I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)
As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.
Besides the obvious 'admin' and 'blog' use cases for a module structure in Zend Framework are there any reasons or guidelines to use Modules? I feel drawn to use modules, but I'm not sure how I would split my web app up into modules.
Can you suggestion some instances where using modules would be beneficial?
Modules are good when you want to reuse them across multiple applications, or when a piece of the application is large enough that it warrants separation into its own chunk. Rather than having a bunch of unrelated controllers in one directory, the module allows you to split up the MVCs into related chunks.
We use modules all the time; our clients frequently pick and choose between the available modules to package an application. We also introduced module dependencies, so that modules may rely on each other.
As a general rule, when our applications have a high level subfolder, unless they have only a couple pages, they are modules. For example, About would only be a controller and a view within the application, but forum might be its own module.
I have way too many modules in my application. Currently my modules are namespaced, but what I'd like to do is have a directory structure so I can get rid of this redundant and annoying namespacing.
For instance, for modules named "xModule1, xModule2, xModule3", I'd like to have a directory structure like this:
-x
-module1
-actions and templates
-module2
-actions and templates
-module3
- actions and templates
Surely the developers at symfony know that people would like to use their framework to develop large applications. So how is module organization like this done?
I've done a lot of work in Java/Spring, and because source is component scanned, you can arrange your controllers and jsp files in nicely organized hierarchies. Is this somehow possible with Symfony?
No, this is not possible with Symfony. The structure of your modules and their actions and templates is expected in a fixed file system layout and I haven't heard anything about that changing.
I've run into the same problem you're facing where a very large site ended up with 30+ modules in a single application. At first it seemed cumbersome but after dealing with it for a while I found that the single location to search for a specific module was in fact beneficial instead of having to guess through sub-structures until I got what I was after. Seeing that structure grow and grow also pushes me to respect adding new modules only when it's absolutely necessary, folding new functionality into existing modules and refactoring existing modules to work with new enhancements whenever possible.
Symfony does have auto-loading features that will work for your library folders however, allowing you to have lib/one/two/three/Object.class.php or any other structure you see fit.
If you have so many modules, you could consider to move some functionality into plugins (i.e. create your own plugins).
The benefit is that you can use this functionality also in other projects.
Or you can group your modules into applications. You can have as many applications as you want, not only backend and frontend.
I've wondered about the same thing, especially as many configuration files need to be set either at application level or individual module level. It could useful to be able to cascade configurations to a set of modules.
As mentioned above, it seems the available solutions are:
deal with lots of modules
create separate applications (which will create some wieldy duplication)
refactor your modules to be as efficient as practical (i.e. multiple controllers & views per module)
In every large application there is an ADMIN section.
In such cases, when not using ZF, I usually put all the admin stuff in a separate directory with extra security measures (like adding .htaccess based authentication and/or a second login etc). This also makes it pretty obvious in the file tree what file is what.
How can I achieve the same design in ZF? Or are there any best practices to create an admin section?
Should I do it in the router level (if there is "admin" in the url, then I use a different index.php/ bootstrap file....)
I guess the simplest was just using a controller for all the admin stuff, but I have too much of that. So I have several admin controllers side by side with the regular app controllers. It makes a mess in my controllers directory - which controller is admin and which is not?
I've done it as a module. In addition to the module link provided by Brett Bender see section 12.3.2.2 in the link I provided.
I generally create a separate "application" folder - complete with its own controller and view directory as well as a public directory for static content - for the entire administration system. The Administration usually has different requirements for key things such as access management, and might differ from the actual application in numerous other ways. Therefore I think it's a good idea to separate the source code entirely. Some of the source code can still be common, though. Examples include library folders and database models.
This approach also gives you larger flexibility when deciding where the admin utility should be available. You could use the apache alias directice to put it in a sub directory on the same domain, or put it on a separate vhost. It's all up to you.
You should check out using modules with ZF. You can have a default module to contain non-admin stuff, and an admin module to contain everything administrative. Using a default module will not change your current URLs and the admin module URLs will look like server.com/admin/controllername/actionname/params. This will solve your controllers all being in the same place and getting cluttered. Also, you can subclass Zend_Controller_Action and make a Master_Controller in your models to keep shared functionality. Then just make an Admin_Controller that extends the master controller for shared administrative functionality and have every controller in your admin module subclass that. You can use a similar structure to organize shared non-admin functionality in your other module(s).
Zend Framework - modular directory structure