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
Related
What is the best way to create a single page module for Yii2?
For example using Ember, I will have index.html and assets folder to publish.
I see two ways, one would be to just put the application under web accessible folder, it will work fine.
But what if i want to check access to the application using existing RBAC?
Another way would be to create a module and in default controller have something like
return $this->renderFile('#path/to/index.html');
And load all assets with Asset Bundle.
The problem with this approach is that i will not know the folder where assets will be loaded (it can be solved with afterCopy callback or something, but all this doesn't look nice at all).
Please advise.
Certainly it is a personal choice technique, since control RBAC is manageable level action and does not pose any problem. Once the controller is easy applicarre your organization's access control using a suitable configuration of the Access Control filter.
Alternatively, the fact of creating a module appropriately for these purposes makes it all the better organized and, precisely, modular, beyond the greater complexity in the creation of the various parts in play (module, asset, cofig / main.php) yii2 handles very well and automatically the assets and necessariio not know a priori in the name of the folder where I finish the specific assets (Yii2 find what they need).
However if this is not a 'module' with reusable application characteristics I would opt for the first solution
I have an application in PHP that is a simplified MVC type structure. This application will be used in over a dozen sites run by my company and others. The structure consists of a controller file, a folder called application which contains the app classes, and a folder called site that contains site specific code such as templates. Periodically, we distribute a patcher that updates the controller and the application folder when we are distributing changes. As a result, clients can't really alter the core code in the application folder without losing those changes when the code is updated.
I tell you that so I can explain what the clients want - they want the ability to extend existing classes. Is there a design pattern that would allow this? Right now, I have given users the ability to replace entire classes:
spl_autoload_register('loadSiteClass');
spl_autoload_register('loadCoreClass');
This uses an autoloader that checks the site folder for a class before looking in the application folder for the class. I am hoping to find an alternative that would allow me to autodetect, load and use classes that extend existing classes instead of forcing the class to be completely replaced. Any suggestions would be greatly welcomed. Thanks in advance.
If it helps, there is also a site specific config file in the site folder, where the site admin can add config settings telling me that a class is being extended, but I'm still not sure how to use that information if it were provided.
The way codeigniter does it is have a mirror directory structure in the "client" / "application" folder of the system classes. Then you can make a file in the same place as the system class, then simply extend the system class and their loading class will look for the override first and then fallback.
Check here for some code examples: https://github.com/EllisLab/CodeIgniter/blob/develop/system/core/Loader.php#L277
Their documentation may be more help to understand their pattern.
I'm sure there are more ways to do this ... but generally convention over directory structure and simple PHP "extends" keyword are what makes sense to me.
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.
The challenge:
I want to modularize my library folder in my zend framework app. This is fine, if you want to put everything in the same namespace such "App_." But the problem comes in when you have a dozen packages such as a SignUp package, ACL Package, Navigation Package, Foo Package etc. Now each packages has some view helpers, some controller plugins, some action helpers plus some other base classes. You could add each view helper path individually, but that could junk up your application.ini file/ bootstrap.
So the question is, is anyone aware of 'Plugin Package' loader for ZF?
To clarify, it would be nice to have a resource plugin that you pass the package name, it adds the namespace, registers some default options like helper paths and then you can configure it to add helpers to Action Helper brokers. Each plugin package might have to have its own ini file or an init class that where the programmer could initialize the plugin package. Any thoughts or knowledge of something like this would be appreciated.
Your question is difficult to find a solution to. ZF doesn't seem to be used in the manner you wish.
For example you want the following packages
Navigation
ACL
Sign Up
These are all completely separate and don't all 'plugin' to ZF in a similar manner.
Navigation needs to be stored and built for each request that needs the package, the navigation object then needs to be used in Zend_View objects or perhaps not. What happens when the navigation is referenced in a view but it doesn't exist?
The ACL package is so specific, it integrates into ZF in a lot of different ways, it needs a Zend_Controller_Plugin, it needs a way of meaningful way of storing and building the Zend_Acl object for querying on an application to application basis.
Sign Up needs a controller, an action and a form which is passed to Zend_View and the form needs to be process. This then needs to be plugged into your ACL object, presumably a database and perhaps various other parts of your site it it requires more specific permissions that fall outside of the use for ACL
Its not impossible to do what you want, but there must be a better way. It almost sounds like your trying to build a CMS with optional, plug-able packages?
The ACL issue I have resolved by having a Library of controllers, helpers, models, forms, etc. A Zend_Controller_Plugin runs and attempts to log in the user, this plugin is run for every app I create, it works well uses an ACL object format which I have used for a while.
For Sign Up I have a RegisterController in my Library, if my application requires registration it has its own RegisterController which extends the RegisterController in the Library. If the application doesn't need registration then it doesn't have its own RegisterController.
I hope that helps, I really think that doing this in the abstracted way suggested isn't worth it and will never be so solid and tight you can truly rely on it because each application is specific.
Generally, in this case you should use modules which are already modularized instead of modularizing the library.
modules/
signup/
models/
plugins/
The default module resource autoloader is configured by default to load plugins:
See: http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html:
If you really need to modularize the library, the customized autoloader will be the best solution (there is an easy to extend abstract autoloader).
You may also consider separate library for each module, added to your include path (not recommended, because it will slow down the app):
modules/
signup/
models/
library/
I have to develop frontend/backend application using cakephp.
can you give me advice how should i develop them, using same cakephp library?
or I have to develop them using separate cakephp libraries?
I am confused - cakePHP would be used to implement both.
PHP would be used to implement the server-side backend. The same "project" would also contain HTML, JS, CSS, etc that will be used to render the front-end within the browser. Any PHP "views" will also execute code on the back-end, although any HTML output will be rendered on the frontend.
Does that help at all? Or am I missing something?
If by frontend/backend, you mean an application with a user interface (frontend) and an administration interface (backend), then you want to refer to the Prefix Routing section of the manual. This will allow you to have separate flow and interfaces (controller/view) for each type of user while sharing the same data (models).
If by frontend/backend, you mean an application (frontend) that communicates with another server application (backend) using web services, then you want to look at the Additional Class Paths section of the manual. This will allow you to share common classes with two (or more) separate applications.
Note: the above links are for CakePHP 3.x, though these features have existed in one form or another since v1.2.
Not quite sure if I understood you correct, but if I did:
You can set up multiple projects using the same cake-core files. The core files don't even need to be placed in the webroot folder..
http://book.cakephp.org/view/35/Advanced-Installation
For your own sanity, you should regard the backend management as part of the same project as the frontend.
The systems I have built generally use view-type methods for the public view and crud-type methods for the admin view. How you lock down the admin is your choice. Personally I don't like the default admin prefix way. I use login and ACL - Mark Story's tutorial on http://book.cakephp.org/ is superb. With that you can password protect methods.
CakePHP is very flexible and extensible and you can make the administration as simple or as flexible as you like.