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.
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.
i just followed this docs api rest phalcon and it worked!, but i don't know how to properly set more resources like robots in the example, if i have 10 resources i don't like to have them in the same file.
using router?
Thanks a lot.
If by resources you mean models and if it works as is, you can simply create more models in my-rest-api/models/ directory. Normally you'd need to configure an autoloader, but micro apps probably know where to get models from.
If you are asking how to make your app better organised you probably need to move away from the micro app and take advantage of the MVC pattern. If in the example you worked with a single model and all related logic was handled in a single file, with MVC all logic is organised into controllers. Normally single controller handles logic related to a single model or models related to it. The official tutorial explores this in depth with further references.
Edit:
And as Julian himself pointed out Phalcon\Mvc\Micro\Collection is another approach for micro apps.
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 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.
I'm looking for advice, tutorials and links at how to set up a mid-sized web application with Kohana 3. I have implemented MVC patterns in the past but never worked against a "formalized" MVC framework so I'm still getting my head around the terminology - toying around with basic examples, building views and templates, and so on.
I'm progressing fairly well but I want to set up a real-world web project (one of my own that I've been planning for quite some time now) as a learning object.
I learn best by example, but example-based documentation is a bit sparse for Kohana 3 right now - they say so themselves on the site. While I'm not worried about learning the framework as I go along, I want to make sure the code base is healthily structured from the start - i.e. controllers are split nicely, named well and according to standards, and most importantly the business logic is separated into appropriately sized models.
My application could, in its core, be described as a business directory with a range of search and listing functions, and a login area for each entry owner. The actual administrative database backend is already taken care of.
Supposing I have all the API worked out and in place already - list all businesses, edit business, list businesses by street name, create offer logged in as business, and so on, and I'm just looking for how to fit the functionality into a MVC pattern and into a Kohana application structure that can be easily extended.
Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3, preferably Open Source so I could take a peek how they do it?
Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?
Do you know any good resources on building complex applications with Kohana?
Have you built something similar and could give me recommendations on a project structure?
Bounty
I'm awarding the bounty to #antpaw because he provided me with a Kohana application with some business logic that is giving me a lot of examples. Cheers #Pixel Developer for your excellent input as well - as so often, I'd wish one could split a bounty!
Lots of questions to answer here, I'll try my best.
Do you know real-life examples of "database-heavy" applications like directories, online communities... with a log-in area built on Kohana 3 where I could take a peek how they do it?
There's a few example applications out there. Woody Gilk (Kohana founder) has published the code to his personal website on github. For the login area he assigns a cookie value. Kohana 3 / 2.4 sign the cookies which makes it safe and removes the requirement for sessions. This might not be up to everyone's tastes so you can always use built in authentication library that uses both sessions and cookies.
Here are some other projects you might be interested in:
Shindig - Light weight blog module for kohana 3
Kohanut - An extensible CMS written in Kohana 3
Are there conventions or best practices on how to structure an extendable login area for end users in a Kohana project that is not only able to handle a business directory page, but further products on separate pages as well?
If I understand you correctly you want to generate a login box for each of those pages? This is easy with Kohana 3 as we can take advantage of the H in HMVC. Sam de Fressyinet wrote an article detailing what this all about on the iBuilding Tech Blog. Scaling Web Applications with HMVC.
What you can then do is perform an internal request to the login controller or action and dump the response into your view page.
$login = Request::factory('login')->execute()->response;
$login now contains the login form, which you can put anywhere you like. You may want to return a different response if the request is internal which is why this piece of code can be useful:
if (Request::instance() !== $this->request)
{
print 'Internal called made with Request::factory';
}
Do you know any good resources on building complex applications with Kohana?
There's not going to be documentation showing you how to build complicated applications. The view of the Kohana community is that you're a PHP developer and should be able to solve these problems for yourself. If you can't, well you shouldn't be using Kohana then.
Have you built something similar and could give me recommendations on a project structure?
Once you understand how Kohana 3 finds files things are easy to understand.
|- classes
|-- controller
|-- model
|- views
For example:
Controller_Mathew extends Controller
Will look for a file called mathew.php in:
classes/controller
Underscores can be used to specify deeper directories. Example:
Controller_Mathew_Davies extends Controller
will look for a file called davies.php in:
classes/controller/mathew/
As you can see, the underscores in the controller name act as directory separators. This rings true for models and vanilla classes.
i would use the auth module that comes with kohana for the login. This will give you the roles table where you can setup the possible permission options and relating them to the users later. After that you can check inside the __constructor() or action_function() of each controller whether the user has the required role e.g. with the ->has() function. You also should use the ORM module, its just awesome, since you have many relations between the tables. Also the __get() method inside an ORM object can be extremely handy.
Its also pretty easy to extend a controller function by setting the new parameter to NULL and checking for that in a if statement. e.g. you need only one function for editing a old entry or adding a new one.
public funciton action_manage($id = NULL)
{
$entry = ORM::factory('entry', $id); // if id is null a new entry will be returned
}
It's also important that you structure the views into sub folders to avoid a messy view directory.