In Magento, i know that you can do the following to get collections:
Mage::getResourceModel('module/model_collection');
and
Mage::getModel('module/model)->getCollection();
This all comes from the fact that you can provide your own custom name for collection
for example: Mage::getResourceModel('module/model_blahblahblah');
so getCollection will automatically find that for you.
My question is when would you actually want to use 'blahblahblah' instead of 'collection'
The difference between 'normal' resource model and collection are:
'normal' resource model -> extends from Mage_Core_Model_Resource_Db_Abstract (for flat type, version 1.6.0.0 ++). It is mainly used to connect with your database, such as get data / saving data to database
collection -> extends from Mage_Core_Model_Resource_Db_Collection_Abstract (for flat type). It is mainly used to get 'LIST' of your data. e.g. : get list of orders
So for your question: when would you actually want to use 'blahblahblah' instead of 'collection'
There is no exact answer for that. It is not a must to use name collection to get the list of data. You can use blahblahblah if you want but of course it is better to stick to the convention (Magento's way).
Naming it as collection will give 'normal' people a picture that it is related with collection (collection usually related with list, in our case it is a list of data / object / etc). What will happen if they see: Mage::getResourceModel('module/model_blahblahblah'); maybe blahblahblah is too weird to understandable by other people (though the name won't be as extreme as blahblahblah)
If you want to change your collection class:
Namespace_Module_Model_Mysql4_Module_Collection
to Namespace_Module_Model_Mysql4_Module_Blahblahblah
then you can use Mage::getResourceModel('module/model_blahblahblah') method for getting collection.
Was that helpful?
Related
I have developed a system where various classes have attributes consisting of a custom formula. The formula can contain special tokens which refer to different types of object. For example an object of class FruitSalad may have the following attribute;
$contents = "[A12] + [B76]";
In somewhat abstract terms, this means "add apple 12 to banana 76". It can also get significantly more complex than that with as many as 15 or 20 references to other objects involved in one formula.
I have a trait which passes formulae such as this and each time it finds a reference to a model (i.e. "[A12]") it gets it from the database with A::find(12) and adds it to an array of component objects which can be used for other processes later on in the request.
So, in essence, it's a relationship. But instead of a pivot table to describe the relationship, there is a formula on the parent model which can include references to child models.
This is all working. Yay! But it's really inefficient because there are so many tiny queries to get single models as formulae are parsed. One request may quite easily result in hundreds of queries. Oops.
I see two potential options;
1. Get all my apples and bananas from the database at the start of the request and get them from an in-memory store instead of from the database when parsing a formula (is this the repository pattern??).
2. Create a custom relation type (something like hasManyFromFormula) which makes eager loading work so that the parsing becomes much simpler because the relevant apples and bananas would already be loaded into the parent model.
Is there a precedent for this? As for why I am doing it like this, it would a bit tough to explain in brief but suffice to say it is to support a highly configurable data retrieval system which supports as-yet unknown input data configurations.
Help!
Thanks,
Geoff
Am not completely sure if it is the best solution, but in the end I created a new directory class for basic components and then set it up in the app service provider as a singleton. The constructor for the directory class loaded all models of several relevant classes and made them available as collections throughout the app.
I'm reading some data from an excel file, and hydrating it into an object of class A. Now I have to make sure that one of the fields of the data corresponds to the Id of a specific Entity. i.e:
class A{
protected $entityId;
}
I have to make sure that $entityId is an existing id of a specific entity (let's call it Foo). Now this can be achieved using the choice constraint, by supplying the choices option as all of the existing ids of Foo. However this will obviously cause a performance overhead. Is there a standard/better way to do this?
I'm a bit confused about what you are doing, since you seem to talk about Excel parsing, but at the same time you mention choices, which in my opinion relate to Forms.
IMO you should handle directly the relationship to your entity, instead of only its id. Most of the time it is always better to have directly the related entity as attribute of your class A than only the id, and Symfony manipulates such behaviours pretty well.
Then just have your Excel parser do something like this:
$relatedEntity = $this->relatedEntityRepository->find($entityId);
if (!$relatedEntity) {
throw new \Exception();
}
$entity->setRelatedEntity($relatedEntity);
After doing this, since you were talking about Forms, you can then use an EntityType field which will automatically perform the request in database. Use query_builder if you need to filter the results.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
In Mage_Core_Model_Abstract there is the getCollection method that is widely used.
But, I had never looked at the getCollection method until now. I can see that all it does is call $this->getResourceCollection()
What is the point in having getCollection and why don't everyone just use getResourceCollection instead?
As for my point of view, it just gives me more clean code for model collection retrieval, without unnecessary typing of word Resource all the time. Also if you look into Order model or Quote model, you will see that it also using simplified method name for collection retrieval of items, addresses, payments, etc.
If it would be named getItemResourceCollection(), getAddressResourceCollection() instead of getAddressCollection() or getItemsCollection(), amount of characters you type during development is increasing. There were no explanation about why getCollection() should be used in favor getResourceCollection() while I was working in core team, but it was quite logical for me to use shorter name of method.
At least non of these methods are marked as deprecated, so you can use them both.
I have two models, Company and Contact.
I'd like to have the following routes (among others):
http://example.com/contacts (lists
all contacts)
http://example.com/company/1/contacts
(lists all contacts for company #1)
For sake of simplicity, the views will be identical except for the page title and breadcrumbs.
What is the best way to setup my ContactsController? Are these two different actions? Would my approach change if in the future I wanted to handle a 3rd type of route such as http://example.com/salesregion/1/contacts?
I'm not very familiar with ruby on rails, but, using common MVC practice, this is how I would go about this solution:
Create a route that is something like this: Contacts/{type}/{id}
Where type can be (company, salesretion, etc.) and id would be the id of that given model. In theory then simply filter the query based on the given type.
Hope this helps.