I am building a CMS based on CodeIgniter and Wiredesigz HMVC plugin in order to expand my PHP and in particular OOP knowledge further. So, I have started, and am already stuck with two best practices issues that I hope someone can help with.
Should the core of my CMS, which will contain all globally used functions such as logging system events, load scripts and CSS for different modules, etc., reside in a library (that make calls to the Core module model) or in the Core module itself?
If I put the core functionality in a module, should my other modules extend the Core (class User extends Core) or should they be stand-alone (User constructor loads Core module)?
you may reference the CMS project pyrocms based on codeigniter framework
I have done more reading on this, but found no real concensus. Some comments said that it depends on what your end objective is. Since there are no other suggestions or answers here, I will consider it a personal choice.
Related
I'm putting together a dashboard for a backend to a CMS project made with Codeigniter. There is some navigation in a sidebar and I"m trying to figure out what I need to know making "modules". I have two types of users. Administrators and basic users. They share the same sidebar navigation. Admins can see all links in the navigation and basic users can only see some. I was trying to look at a few different CMS's to see how they do it and really like how PyroCMS does it with putting together their navigation. However, I"m trying to find out what really tells me what I should makes a module. I know it has its own controllers, models, views and etc. I'm trying to find out with research what I need to know to really know what should I make into a module. Are their questions I should I should be asking myself that will be able to tell me what has the possibility of being a module and what isn't.
CMS Admin_Controller Line 80
Module development with PyroCMS is the way to go if you're used to working in CodeIgniter.
Becoming acclimated will be intuitive as a CI programmer, create a new module (drop it in your *addons/shared_addons/modules* folder):
https://github.com/pyrocms/sample
And notice how the routing works:
http://docs.pyrocms.com/2.2/manual/developers/basics/modular-routing
Then take a looksee at MY_Model (system/cms/core) that PyroCMS includes. I wrote a few modules before realizing PyroCMS includes a basic model that will save you from writing a lot of extraneous code. Don't worry, you can still always choose extend CI_Model instead if you don't want to use MY_Model for a module.
The more you learn about the mechanics of PyroCMS, the more you realize it has no limits. Unless you're writing trivial apps or just like re-writing code, I wouldn't start any new project in CI because PyroCMS is the more sensible starting point.
If there is something more advanced that the documentation doesn't answer for you. Then SNOOP AROUND! All the core features are built as modules. Check out how they did it in one of the core modules (system/cms/modules/). And if you want to change something in the core, you can avoid make any changes to the core by overloading views.
Once you're confident with your ported CI App, I would check out Streams. Streams will dramatically increase the time it takes to write trivial CRUD modules. If you're as happy as I've been with Pyro, you won't mind shelling out the lettuce to buy PyroCMS Pro or Streams.
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.
I'm starting to familiarize myself with using the module-based architecture for zend framework projects. My real reason behind being interested in the module architecture is to be able to take a module from one project and just drop it into another project. Maybe I'm not getting it right..
But what I'm noticing right off the bat is that controllers within each module cannot have the same name as any other controller in the main application (or in any other module, though I haven't tested this). This leads me to think that modules are not really independent self-contained units, so I wonder how this affects their ease of distribution from one project to another.
The other issue is what if I were to take a module and drop it into another project. Do I have to update the .zfproject.xml manually? and wouldn't that be a bit too cumbersome to be done manually?
Maybe I'm not clear on how modules should be used in zend, so I'd like to know when you decide it's best to use them, and when do you decide not to use them, or do you use them all the time, or do you never use them?
I always used module based architecture so far in my projects, because I like to separate concepts. For example I have always an ADMIN module whose classes and controllers dont mix with the rest of the application. Using modules you can reuse modules for other applications, for example if you create a BLOG module.
The names of your controllers will be something like Admin_IndexController for the admin module even if the file is named IndexController.php.
Another concept that is nice and help you reuse resources is the plugins. Use them for authentication or to check validity of the requests.
You need to setup namespaces for your modules so that they are easily moved into a new project without renaming.
If you are using Zend Tool then you will have to edit the zfproject.xml. I haven't spent a lot of time using this so I'm not sure if there is another way without manually editing.
I have recently started working on an eCommerce site for a company and they have selected Magento 1.4.0 to run their store. I have spent most of my PHP "career" working with various MVC frameworks (even Zend with Magento is supposed to be based on) but the complexity of Magento seems to be on another level with no seemingly good resources to look to for help.
Looking around the site I have seen suggestions for certain books to use as reference, but they all refer to Magento 1.2 or 1.3.
My goal is to develop for Magento in a way that I do not alter any of the base code so that the client can easily upgrade the version of Magento and just "drop in" my code and have it work. The current issue is how to properly use the layout/template breakdown correctly and how to add custom model/controller functionality to the application without hacking away at Magento's core code base.
how to properly use the layout/template breakdown correctly
What you need to know is the folder structure of the Magento & the use of its own MVC structure. This is a very very important part to get you started from the basic roots. Whatever version you use, the folder structure & the MVC structure followed by Magento will almost never change. Try to follow the Magento's own Knowledge Base & Wiki tutorials. If you want you can also follow some other sites as well.
how to add custom model/controller functionality to the application
without hacking away at Magento's core code base
You will need to use the custom module functionality to override the core code base of model / controller. It's a simple process of writing the main logic in a XML file, of what core class you want to override of Magento, in your module's "etc" folder. Try to understand the process first, from the Knowledge Base & Wiki tutorials, to get a firm grip on overriding core classes.
I hope this helps.