I am working in a huge project, in CakePHP. Its tough to handle a huge system like this. So, I want to divide this system into 2 sub-systems. There will be same database, with same tables. Both sub-systems can use all the tables. I just want to make 2 packages of Controllers, Models, Views; I mean, both package will have their own Controller, Models, Views, and they may interact if they need to.
Its like HMVC of Code Igniter, triads of MVCs.
Is that possible ? If yes, how ? I am asking for any code, I am asking for the way to organize my system(site) in a systematic way.
Thanks.
The equivalent of HMVC in Cake would be the plugins. You can make as much plugins as you like in order to modularize your project.
Although making your code modular (using plugins) is good, you need to keep the reference to the plugins in the rest of the site/project.
As example you always need to place plugin in the link in order to keep the proper links like
$this->Html->link('Your link', array('plugin'=>'my-plugin', 'controller'=>'my-controller',....));
Apart from that I think there are a lot of benefits making your project modular.
Related
What's the best way to handle the scaffold when it comes to the deployment stage?
Leave it there? But then what's the best way to protect the access of it?
Remove it? But then I need another system to access all the data, right?
How do people usually handle the scaffold in CakePHP which is very useful in the building process?
Most people would not use scaffold anymore when getting close to deployment.
That is where "bake" comes into play.
You usually only scaffold while still changing the database structure heavily.
As soon as it gets stable you use custom bake templates to bake your views to real files.
I actually never use scaffolding as bake has way more advantages (such as full customization of the template output.
And rebaking is not that big of a deal. It is pretty fast to achieve.
I am using backbone.js in a legacy app to rewrite separate pages into individual bits of backbone work.
I am not using any routing and it is not a total single page application.
Only certain pages are individual backbone.js applicaitons.
At the moment I have all my backbone javasript in one file for each page that uses it which is painful to work on.
Would it be wise to use something like requirejs on a page by page basis or is there something better I could do in order to split the page up in development and serve one page in production?
That depends largely on what your existing codebase looks like.
RequireJS is a great tool...if your existing code is set up to support it, or you have a small enough codebase to be able to convert it without breaking everything. However, not all legacy JS code is, especially if it's part of a larger system (I personally ran into this problem with a Backbone project I'm working on). If you can, then by all means, make use of it. The big advantage, as far as I know, with RequireJS is that it doesn't actually fetch and load the Javascript files until you need them. So you can have one RequireJS call that's in all of your pages, and only download what you need, when you need it.
There are other ways, however, to combine your Javascript code at production time, which, again, depends greatly on your setup. Many content management systems include "minify" scripts that handle it automatically for all of your Javascript files. You can also do it "by hand" with Minify, YUI Compressor, or one of the many other minification tools out there. (You can also do it "really by hand", and develop in multiple files and combine them via copy+paste, but that's really more work than is necessary.)
Regardless of how you go about doing it, I highly recommend breaking your projects into multiple files (not only into a file for different projects, but multiple files within the projects, to hold each view and models if they have significant code). It makes it infinitely easier to maintain.
I'm developing a CakePHP application that we will provide as a white label for people to implement for their own companies, and they'll need to have certain customization capabilities for themselves.
For starters, they'll be able to do anything they want with the views, and they can add their own Controllers/Models if they need to add completely new stuff. However, I'd rather advise against touching my controllers and models, to make version upgrading easier.
Esentially, the customization capabilities I'm planning to give them are going to be quite basic, I just need to call "something" when certain things happen, so they can do things like update external systems, e-mail themselves/the clients, things like that.
I'm wondering what's the best way to do this?
My plan is to have a "file" (with one class) for each controller of mine, to keep things reasonably organized. This file will have a bunch of empty methods that my code will call, and they'll be able to add code inside those methods to do whatever they need to do.
The specific question is, should this class full of empty methods be a Component? A Controller? Just a regular plain PHP class?
I'll need to call methods in this class from my Controllers, so I'm guessing making it a Controller is out of the question (unless maybe it's a controller that inherits from mine? or mine inherits from theirs, probably).
Also, I'd need the implementer of these methods to have access to my Models and Components, although I'm ok with making them use App::Import, I don't need to have the magic $this->ModelName members set.
Also, does this file I create (etiher Component or Controller) have to live in the app folder next to the other (my) controllers/components? Or can I throw it somewhere separate like the vendors folder?
Have you done something like this before?
Any tips/advice/pitfalls to avoid will be more than welcome.
I know this is kind of subjective, I'm looking to hear from your experience mostly, if you've done this before.
Thanks!
Two ideas that spring to mind:
create abstract templates (controllers, models, whatever necessary) that your clients can extend
write your controllers/components/models as a plugin within their own namespace
Ultimately you seem to want to provide an "enhanced" Cake framework, that your clients still have to write their own Cake code in (I don't know how this goes together with your idea of "basic customization capabilities" though). As such, you should write your code in as much an "optional" manner as possible (namespaced plugins, components, AppModel enhancements, extra libs) and provide documentation on how to use these to help your clients speed up their work.
I would setup a common set of events and use something like the linked to event system to handle this.
That lets the clients manage the event handler classes (read the readme to see what I mean) and subscribe to and broadcast events application-wide.
Also - if you want to have your users not muck about with your core functionality I recommend you package your main app as a plugin.
http://github.com/m3nt0r/eventful-cakephp
I know it has great out-of-the-box features but is it easy to customize?
Like when I query stuff from the database or change css layouts.
Is it faster to create my own modules for it or just go on and write everything from scratch using frameworks like Cake
I'm currently working on an Elgg-based site and I absolutely hate it. The project was near completion when I stepped in, but the people who created were no longer available, so I took it over as a freelancer.
As a personal impression, you are much better off writing the app from scratch in a framework. I don't know if the people before me butchered it, but the code looks awful, the entity-based relationship model is wierd to say the least and debugging is horrendous. Also, from my point of view, it doesn't scale very well. If you were to have a consistent user base, I'd be really really worried.
It keeps two global objects ($vars and $CONFIG) that have more than 5000(!) members loaded in memory on each page. This is a crap indicator.
I've worked extensively with cake. With Elgg, for about a month in a project that is on QA stage right now.
My advise is: if you need something quick with a lot of features and you only need to customize a little, go with Elgg.
If you're going to customize a lot and you can afford the development of all the forums, friends, invites, etc. features, go with Cake or any other MVC framework.
I have been working on a Elgg site for the past month or so, its code is horrible, however it's not the worst I've seen :D. it's not built for programmers like Drupal is :D. But it's not too bad. Once I got a handle on the metadata functions and read most of the code I was able to navigate it well and create custom modules and such.
What would help immensely would be some real documentation and explanation of the Elgg system. I don't think that's going to happen though :).
Out of the box there are a few problems, there are some bugs that haven't been fixed for a while and I've had to go in and fix them myself. Overall, you can make it pretty and it has some cool functions, but i wouldn't dive in until i had read the main core code to get a handle on what's happening on the backend.
Oh and massive use of storing values in globals. and a crap ton of DB calls (same with Drupal though).
i wonder if the use of storing everything, and i mean everything for your site in the globals will really hinder the server if you have a massive user load.
If you want to build a product based on a social networking platform/framework then Elgg is definately a good way to go. The code is not that bad if you actually look before leaping and doing what elgg expects. You go against its processes and structures and it will leave you beaten by the side of the road.
Developing modules/plugins or editing CSS is easy and Elgg does give you great flexability to basically build your own product ontop of it. Dolphin, as comparrison, does not allow you to do anything outside of what it expects you to do.
If you however just need a framework (not primarily for social networking etc) with some user based functionality then i suggest Cake, or if your project is HUGE then maybe Symfony or Zend. They all have plugins you can download and use/hack which would be easirer to adjust for personalised needs.
To show what you can do with elgg here is a site Mobilitate we built with Elgg 1.7. This is a very complicated website and was built ontop of Elgg.
We are starting a new project with Elgg 1.8. The new version is a major improvement they have made a lot of elements easier, incorporated better JS and CSS implementation/structure and have better commented their own code.
Elgg's database schema is horrific. They've essentially implemented a NoSQL database in SQL. It completely defeats the purpose of using a relational table structure.
If you can ignore this, and aren't doing much customization, you might be OK with Elgg. If not, STAY AWAY.
I've been working with Elgg for over a year. It is easier to customize than it would be to build something from scratch using a framework like CakePHP. I tried CakePHP and found it even more complicated than Elgg.
It is difficult to query the database due to the entity-based relationship model. You should use the build-in methods for accessing data. However, I have written many queries to double check on what is actually stored in the database.
You cannot change layouts using CSS alone. You have to deal with the various Elgg views. But CakePHP uses the same Model/View/Controller MVC concept so that would be just as difficult.
If I am using CAKEphp do I need to use smartytemplates too?
No.
Cake has its "own" templating system which uses .ctp files, which are just straight HTML/PHP files.
You can integrate pretty much anything with Cake, including Smarty. When I first started, I thought about doing it and my advice is don't. You just don't need to. Cake's own templating system is fully featured and comes with a lot of helpers, integration, convention etc. (not to mention online wisdom).
Having another template system will only make life complicated. Apart from that, think of the practicalities of pushing two codebases around, maintaining them and wearing different hats depending on which part you're working on.
CakePHP is delivered with all you need to build most web applications.
Not necessary. The smarty templates are optional, if you wish you can use them or leave them.