I recently started with CakePHP and so far I'm loving it, specially the scafolding and bake.
I'm building a webapp that will manage applications to companies. (i.e., where have I applied to, with whom have I spoke, the status of the application(s), how long ago has it been since I did sent/recieved a communication regarding this application.)
I have a model Application and an Action model. An application has multiple Actions.
When you add a new Application, it does not make sense to add "just" the application but to add one action. Is there anyway to have my applications add view to connect with two controllers and add the action and application simultaneously?
Please do let me know if my problem is understandable or if you need further clarification.
Thanks.
Yes, you can. See this question.
Related
So this past year I have dived into professional web development using laravel, and the journey has been amazing, with stackoverflow helping me tremendously. This question is more of an opinion rather than me asking how to do it. So, I'll break it down with an example.
Suppose I am creating an articles website. For the articles, I create a migration, model, controller and then views. For migration and model, it only requires one set of it because only one table exists for it. For views I have separate folders for admin panel for backend and frontend. Usually in the routes I'll create a group for backend with prefix of admin and auth guard which comes built in with laravel, though in the newer versions of laravel you gotta do composer require laravel/ui. Now, because I have different routes for both backend and frontend, logically what I do is create a completely different Controller for the backend with all the CRUD functionality, and for the frontend I make a separate controller and put index and show function in it.
Is this the best way to deal with it, or is there a more efficient way of handling the backend and the frontend? Also, is the basic workflow of development usually the same as I have mentioned, or do you people have a different take on how to do these things. Please let me know.
Cheers :)
In most projects, frontend and backend, are two different environments with different needs, so using the same controllers would be inappropriate as it might lead in complex - no-clean code.
What works for me best, is to separate the controllers in the following groups:
Frontend
Backend
API
In some cases you might also need a group for the controllers handling the ajax/async requests, i.e. Async group.
So basically, I have this project I'm planning. A kind of "social network".
I was just wondering, as for now, I have a single controller (ProfilesController) wich takes care of status updating, profile editing, gallery uploading / viewing, settings etc.
Is this a good structure? Or should I separate it into different controllers like (ProfilesController, GalleryController, SettingsController, GuestbookController)?
And my models, I currently have Guestbook, PhotoAlbum, Profile and User models. Is this good? Or should some of theese maybe be merged into User or Profile?
Thanks in advance.
I think to keep things as RESTful as possible you should have separate controllers for the separate models. Your models should definitely each be their own files/classes.
1. Following the principle "single responsibility" okay that you create a controller for each process.
2. Laravel each table (that you used in the project) of the database must have a Model.
3. If you want to do good things would recommend to follow the principle "first API": Designing the structure of your API and then begin to program it. Having done this, recently begin to develop interfaces and your processes using your API.
I would stay with REST and really create For every table, a model and a controller. So you can develop your application in a very clean way.
If your "social network" or whatever application you want to develop will get bigger and more complex, this is the best way to keep it clean and clearly represented.
Once I started a small Project and was not really caring about following this principle, but you will get to the point you regret it.
So start your Project with a clean structure and create for every Model a Controller.
I recommend to also use the Route::Ressource for defining the basic routes. So you follow all the conventions.
Route::resource('Model', 'ModelController');
For more informations, check the docs.
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
I am testing an MVC framework to use in my project and i have few questions regarding the YII.
I have create a model using GII, I know from java the code generation suppose to be a helper and most of the time should not be modified, because you may want to regenrate in the future, how is that suppose to work here?
I have created a CRUD out of the model and it gave a nice gui for it, I want to keep the gui for the admin side but i want to do a different one for the user side, what is the approach here?
If i am deciding to use some ORM in my app, this means that i need to create a different model, and i see that the current model inherits from an other one... problem?
In general
Which is suppose to be faster in terms of load, CI? or YII?
correct me If i am wrong but MVC architecture does not really gives you a way to be really OOP, like java. interfaces, inheritance and polymorphic, it is a nice way to build a nice app quickly, not more than that. I am saying that because your controllers and model are already inheriting some classes.
Thanks
1) Usually models work ok after generation and most of time there's no need to change anything. If you add a field in your database and you need to regenerate it, when you do that you have in gii what's the new code, so you can copy/paste. Usually you don't need to do that, when i add fields to a database I add those fields in the model "by hand". Very easy and quickly, trust me
2) use templates. Create a new template in your layout views, and assign it to the controllers of the front end with $this->layout = '//my//layout';
3) Yii AR implementation is enougth for me. Can't answer to this questions, but you should not have any problem.
4) Depends on what kind of app you are running. I have worked with CI and Yii, i prefer yii for developer time and for speed.
5) You are "right" with that point.
I am looking at suitable architecture for a Codeigniter based application , the requirement is such that end of the program I must be able to reuse certain modules , completely.
I was looking at a solution like HMVC.
I need to know if this is the best solution for my problem.
To build a set of independent modules that can be reused with minimal changes.
Regards,
Gayan
At what level do you want to reuse "modules"? For example, the models that you create could be reused on a different web application, since they will simply be an interface between your web application and the back-end database.
If you create REST web methods using a framework such as CodeIgniter REST Server, those methods might also be at a suitable level of generality that they could be re-used as well.
I suppose the next question is, do you need and entire 'module' of code that can be copied out of this app and pasted into another one? If that is what you are looking for, then HMVC would be the final piece of the puzzle that you can use to tie everything together - just create this general code within one or more modules.
Does that help at all?