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/
Related
I have created a set of class files that helps to create the route configuration array. I, however, do not know where to put the source files. I browsed around a little and found some answers that suggested I put up the code in packagist and install it via composer, but my classes are relatively small. So, I wanted to ask if there is another way to do it. The files must be accessible in all the modules.
Your application code is organised into modules and lives in module/<Modulename>/src/. If the code is something you might want to reuse in other applications, then it might make more sense to have it as a standalone library that you install via. Composer.
You're code is accessibly through all the application if it is configured in the composer.json's autoload section.
Code structure in ZF is quite simple. You have your modules and in every module you have an src directory. This src directory should have its own namespace. And there you can place your custom route configurator under this namespace, like 'ModuleName\RouteConfigurator'.
But if you use this logic through multiple modules, I suggest you to create a separate module for it. In this case, after a long road, you may consider creating a separate composer package from it. But it's not necessary.
If you're not familiar with defining modules, please read the zend-modulemanager's documentation (https://docs.zendframework.com/zend-modulemanager/intro/)
Does CakePHP's bootstrap.php file have to do anything with the Bootstrap.js framework?
Is there any specific reason behind this file being named as such?
Bootstraps refer to a configuration file that includes the autoloader ( if present ) and any credential parsing/loading for a specific project.
The concept allows you to use a library in many projects only having to customize one file for each database/setup/modules to include/exclude.
Bootstrap framework was nicely named to suggest that using it will be synonymous to the bootstrap concept? ;)
No, it is unrelated to the bootstrap framework.
The point is to provide a single point which, by design, allows the core app/configuration to be extended in a variety of ways, as suggested by:
http://book.cakephp.org/2.0/en/development/configuration.html#bootstrapping-cakephp
Code + comments in the bootstrap.php file maintained with the release provide guidance on specific uses. FWIW I find it convenient to include bootstrap.php in my version control repository, while excluding core, database & email configurations so they can be maintained separately on my development & production server(s).
No, the two things are completely separate in all ways, other than their name.
Bootstrap.js
Bootstrap.js is a project, originally created by Twitter, to be a client-side development framework that encapsulates the workflow of HTML, CSS and JavaScript into an easy-to-use API. The project's tagline:
Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.
I am not, personally, aware of the reasons why they named it 'Bootstrap' (it was originally named 'Twitter Blueprint', blueprint making a little more sense since it defines the structure and outline of your application).
CakePHP's bootstrap.php
CakePHP's bootstrap.php file, on the other hand, represents the actual term "bootstrap". Rather, the process of "bootstrapping". Because of this, the name bootstrap.php fits really well!
In general, bootstrapping is:
the starting of a self-sustaining process that is supposed to proceed without external input
A better summary, keeping CakePHP in mind, is to say that the bootstrapping process in MVC applications (e.g. CakePHP) initializes "core" (i.e. used and available by everything in the application) configurations such as global constants, model / view / controller paths, or even loading other configuration files.
The Configuration documentation for CakePHP has several examples of how the application itself leverages bootstrap.php in this way (just search for "bootstrap.php" while on the page and you can jump through the examples). At the very bottom of that same page, you'll find a section on Bootstrapping CakePHP which outlines several reasons you'd want to extend it yourself (a few of which I mention above) =]
Right now I find out that extending modules in CodeIgniter framework using MX HMVC is very bad and not supported by default and I have a custom function in MY_Controller and you need to make a "hack"..the main point is it doesn't work good.
My question is if CodeIgniter didn't offer extending modules with other modules e.g. Drupal way of modules. Where e.g. you have core Views module and than module for extending Views so you can have Slideshow as a view and then another that add something else to the slideshow and every module use something from previous module in hierarchy like:
Views -> Views Slideshow -> Views Slideshow Extended
Which PHP frameworks has this "extending" ability in modular way. I am not looking for extensions of classic MVC controllers/models like:
class Views Slideshow extends Views {...
I need a PHP framework that have in mind extending of modules/bundles/whatever-packages
I have a hard time with CodeIgniter so I am looking for some other framework that is capable of this within a core. Thanks for your help.
Symfony2 definitely have this in mind, as everything is a Bundle. Even the framework is a Bundle.
You can pretty much overload almost everything in Symfony2, given that you use the service container instead of hard dependencies. Be careful that this might introduce some complexity (the price of the overloading feature). Also you can reduce complexity (and learning curve), as using the service container is not mandatory.
Please take a look at the documentation of Symfony2: Architecture, and more specifically the Understanding the bundle system
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.
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