I’ve built a PHP ‘personal profile based’ website that has a number of ‘Category’ pages, each of which list a number of Profiles.
Category page: Lists profiles (images/names in a gallery-like layout)
Profile page: Shows in-depth information about one person/profile
Im using a kinda-MVC-esque architecture here. So, when a visitor goes to a Profile page, the appropriate Controller asks the ProfileDataMapper to fetch the relevant profile. The ProfileDataMapper returns a fully formed Profile Domain Object to the Controller which then sends it to a Template View.
The domain objects are all populated from arguments to their constructors, and have validation checks in them so that if any arguments are missing or bad, they will throw an error and not be instantiated.
The problems start when I want to list a number of Profiles on a Category page. Here I am asking the DataMapper for an array of Profiles. But it is returning a list of whole complete Profile Objects when I know that in this case I only need perhaps a Name and URL. It is putting too much strain on the MySQL DB behind the mapper.
The obvious solution would be to simple make the DataMapper pull just the few fields I really need for the list. But then my Domain Model validation tests would fail due to missing data (they are expecting all fields).
So now I am thinking I should create a new Domain model called PartialProfile or ListableProfile. This domain model would just have a name/url and would only validate those two fields. The ProfileDataMapper would return PartialProfiles in its list method instead of Profiles. Maybe the Profile could even extend from PartialProfile.
Is this 'partial model' a good way to go? Or should I refactor my validation code somehow? It seems to me I need different 'levels' of validation. Sometimes I need the object with all data. Sometimes I don't.
Thanks kind people!
Related
I think I understand the concept of HMVC after reading this question and answer https://softwareengineering.stackexchange.com/questions/220480/hmvc-and-database-connections; an extract from an answer is below:
Let's assume you want to have a view that enables a user to make a
comment to a blog post. You would have fields for name, e-mail, title
and comment, but you also want to have a field country displayed as a
dropdown. In the action that displays this view you would make a
database query that loads the countries and then populate that
dropdown. Which is ok, but it forces you to duplicate the query and
the view required to display the countries if you need it in another
part of your application. A better approach would be to create
separate controller for countries with an action that returns a view
with the dropdown and then render that action whenever you need to
show a list of countries.
What I cannot wrap my head around is that if I can internally request a controller/model/view which just displays a widget (e.g. a country select box), doesn't that mean that by accessing that url from a browser will also just show that view?
How is this managed in HMVC, are routes defined as internal/external only, so matching an internal route with an external request would show a 404 page?
Is this generally how it is done and is the HMVC description/definition above satisfiable with the general use case of it in most web applications?
Showing the output of a sub-request in the browser shouldn't be a problem, so I wouldn't bother, especially that those URLs are not known by the user and it's safe to output the widgets separately.
Despite the above, you could, as #deceze mentionned, not attach those controllers to any routes. If you have a "default" route (matching all requests), then you would have to disable it.
Ok, lets say there are two associated models, where the main model has a hasMany relationship with the other model. ex Donor hasMany Donations. I have read most of cake's documentation and I also took note of this (from the doc):
'When working with associated models, it is important to realize that
saving model data should always be done by the corresponding CakePHP
model. If you are saving a new Post and its associated Comments, then
you would use both Post and Comment models during the save operation'(http://book.cakephp.org/2.0/en/models/saving-your-data.html)
And as also pointed out by #burzum on another one of my questions : CakePHP - Controller or No Controller? , I am still struggling on how to decide which works best.
So taking the 'Donor and Donation' example mentioned earlier, let's say we want the user to add donation to a donor. So for the user to add a donation, one would need to view a donor, accessing a url of the sort : 'domain/donors/view/1', meaning the user is currently viewing donor with id of 1. Then within that view, let us assume there is button which allows the user to add a donation. Now from what I have been told and from what I read, the add(donation) action should belong to the donationsController.
Let us also assume that the add(donation) action has its own view.. So if I am at 'domain/donors/view/1' the user is redirected to 'domain/donations/add/donor_id:1' where the id of the donor is then retrieved using
$this->request->params['named']['post_id']
and set to the FK like so :
`$this->request->data['Donation']['donor_id'] = $id;
But I have a gut feeling telling me that this is not the proper way to go and it feels like bad practice jumping from one controller to the other, when having associated models.
Any insight on this ? Is there a general rule of thumb one could apply or follow ? Is it ok to redirect the user from the donorsController's view action to the donationsController's add action ?
Thanks in advance!
As far as I know your approach is not wrong, and linking other controllers from a view is normal.
However i prefer (and that's my rule of thumb, i'm not sure is a "best practice") to give the user the change of add an associated model - donations in your case - directly from the view of the "main" model. I've used this kind of approach in my applications, mostly considering the user experience (don't know if it is your case). So, if you are in the edit action of Donor, in the respective view the user can add the Donation and send it to still the edit action of Donor. Here you can save the associated model if the request data are well formatted:
data['Donor'] = array('id'=> XX);
data['Donation'] = array('id' => YY, 'amount' => blabla,...);
$this->Donor->save(data);
That would respect the MVC (no ugly ClassRegistry::Load ... ) and keep the code simple, avoiding to jump from one controller to another.
Just my opinion :D
Regards.
So, I am fairly new to Zend 2 and MVC as a whole, and I find myself in a situation where I want to follow best practices to make my code reusable and easy to understand.
The particular scenario I want to deal with is the following. Let's say I am writing an editorial application, where users can send articles, but they need to be approved before they are published. When you access an article /article/view/101 , you get a page with the article info on one side (Status, Author, Date, Title, Body) and on the sidebar you get a set of actions.
The set of actions (links) changes based on the type of user viewing the article (guest, user, reviewer or admin) and also based on the status of the article (draft,finished,published)
So the question is: Where do on the MVC model do I put the business logic to decide which actions (links) to put on the sidebar?
The controller does not seem appropriate because I would be adding Business Logic there, and also adding HTML (bad + bad)
The view does not work either because I would be adding business logic.
A service doesn't seem to work either because it seems I would be either adding HTML, or calling partials from there, and that should not be done either...
The only thing I could think of is doing the Business Logic in a service or helper (since more than one model is needed, article and user) and return an 'array' of actions (no HTML). Then the view processes those to actually get the HTML, but I'm not sure if that is the way to do it, and wanted some experienced input.
Im almost scared to ask questions around here these days because I useually get flammed on and told my question is dumb, but here it goes anyways...
Im new to MVCs and im starting to get the hang of them, but one thing im unsure about is if 1 controller is suppose to load a entire profile that has multiple components (i.e a notification beacon, a friend feed, a list of friends that displays thumbnails , a place to post statuses ect...)for the purposes of this post assume im asking if alll the loading for a entire facebook profile should be done in one controller?
Or do i separate each dynamic component into its own MVC and then glue them all together in one main controller or....?
another idea i had was that maybe u do separate each component , but instead of having one main controller you call them as needed in the index.
You could use one controller for the Profile (using your example) and have multiple models fetch and process all the data you need to show. This way even a big page can result in an easy to understand controller that is not so big.
I am building a Web application that allow people to subscribe to certain classes which are divided by semesters.
In one of my interface I have a list of all activities that act as a summary in the backend interface. I was looking to group them by semester and browse through a sequential navigation.
My problem is, where should I put my code since I want it to be easy to maintain and I want to respect the right MVC structure.
Here are my Ideas:
Get the param value in the controller, get the previous and next semester through an
action helper, send the data to the view and then display it
or
Get the param value in the controller, sent it to the view, let the view (through a
view helper) find the previous and next semester and then display it
I have a class that is able to find the semesters through calculation (so it's not in my models)
The first option. Your question is unclear to me, but your first option sounds the closest to what I would do.