I am using this awesome framework during 6 months and I learnt a lot about it, but I wonder if it's possible to create an internal structure to simulate modules like in Codeigniter. I know there is the possibility to use plugins for that, but it seems too difficult to connect it together and pass info between them.
My goal is to get a joomla like modules, but how can i do that without changing the cakephp core? is that possible?
What I am doing for the project I have going on right now is to have the following
In my bootstrap.php
<?php
....
App::build( array(
'plugins' => array(
join( DS, array( null, 'Users', 'abryant', 'Sites', 'appName', 'tools' )),
),
...
));
?>
Then, I keep all of my utility plugins in the tools plugin folder. This is for plugins that you use as internal utilities that don't provide controller / action pairs. IE plugins for behaviors, components, stuff from github etc.
One of the plugins I always grab for my stuff is Eventful which allows you to handle event dispatching and receiving using event classes similar to controllers or models.
Then build a main AppController that has a corresponding AppControllerEvent class in the folder the instructions tell you to use. You can then keep your plugins folder clean for modules which provide controllers, views or some other direct user interaction.
You can use Eventful to broadcast events from plugins down to the App at the AppModel, or AppController sort of level. If you think about this carefully you can use an app level event to ask for responses from installed plugins and then cycle through a set of events to register blocks or inject information into the set view variables.
A lot opens up when you use events and think about how the events communicate with your app.
Well, you are right. Modules in Joomla are independent packages of code wich works like packages in linux (modules maybe depends on other modules), but all of them work over a core functionality. What I want to do is write a core over the CakePHP framework, wich includes the functionality to manage all kind of modules in the system, but I don't know what is the best way to modify CakePHP core to handle this situation...
I did this before with Codeigniter, and because of that I thought to come back to Codeigniter, but Cakephp helps me to create apps in less time... If it may be possible, it would be a great system.
Every module code should be inside its own directory, which includes a controller directory, models, views, config, etc... like a mini CakePHP app that extends the modified CakePHP core. I thought it can be done with plugins, but the way to interconnect them and pass info between them don't seem the best way to do it.
I hope you understand my explanation, sorry for my english.
Initially it seems very difficult, but I think it is the best solution for this problem.
Did you code plugins for all your modules? Or did you code the core in controllers, models, etc.. and extra modules inside plugins? It is weird to me to work this way in CakePHP.
I'll try to code all the modules apart, I mean a core plugin, settings plugin, modules plugin (to manage the other plugins), etc... And probably I'll use bootstraping.
Thank you very much for your answers and sorry for my bad explanation of my problem, but my idea was so general that I couldn't explain it better.
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.
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.
I have seen lots of pages about Yii Boilerplate setup like: http://www.yiiframework.com/wiki/374/yiiboilerplate-setup-a-professional-project-structure-in-seconds/.
Is there any step by step instruction about creating a new basic YiiBoilerPlate app or maybe I am totally wrong about it!?!?!
Just build your app to fit your needs remembering to keep project specific files in separate folders, separate from base application components, like common extensions. I highly recommend using modules. You can have for example user management module with login, logout, profile etc. functionality, and depending on concrete project requirements just drop in more modules.
Mentioned boilerplate is more complex than standard Yii setup. There is one thing i really dont like, is that mudules are in both frontend and backend, and according to yii philosofy, module should be like mini application, so from this boilerplate seems that one should build separate mini apps for frontend and backend... But it is just a taste what you feel better.
If you are new i recommend standard setup, but using modules from beginning. Modules are something like mini app, which can operate on it's own. This way you can build your portfolio of modules, and then when doing some new project you can compose it much quicker and sturdier. A bit more tricki might be interoperability between modules, but thats a whole different story.
You should refer following article.
http://myprogrammingtut.blogspot.in/2013/04/step-by-step-setup-yiiboilerplate.html
which worked for me :)
Hope it'll help you.
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 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)