My Ember data is database-based, but Ember maintains its own copy. So while the CRUD calls return sorted data always, it gets out-of-sort in Ember when data is added. The obvious fix is to have Ember stay in sync with the database, but that seems to violate the premise of Ember, plus there's no obvious "reloadAll" call.
But there's also no obvious "sortBy" that applies from a model. I did try adding a...
phrasesSorted: Ember.computed.sort('phrases', 'phrase')
to my phrases model, but couldn't figure out how to get it referenced from the component (e.g. {{#each model.phrasesSorted as |phrase|}} doesn't do it.)
What's the Embery-way to easily present data sorted? Is this a case where I need to write a bunch more code - e.g. custom routes and controllers - to do something that seems simple, or just me missing the simple?
You use computed.sort in wrong way. Please use:
phrasesSorted: Ember.computed.sort('phrases', 'phrasesSorting'),
phrasesSorting: ['phrase']
Then referencing it via model.phrasesSorted would just work - no matter if inside controller, template, route, component or service.
Related
i'm doing a app and i have an ajax call that send the data to the server and ask the db,it retrieves me the object data.Until here everything is cool.But i want to do a route with routie to retrieve the results on it'own page. the problem is that the two component are at the same level on the hierarchy, so cant get the props of the state data 😥. I've heard about flux but it's a pretty complex architecture for the project that i'm doing. Do you guys have a good pattern to solve that ?
Very Gratefull ;)
I dont think you need Flux for this. You can not (or at least should not) pass data between Components which are on the same hierarchy level. You should read the following lines: https://facebook.github.io/react/docs/thinking-in-react.html#step-4-identify-where-your-state-should-live
It gives you same hints on how to decide where to put your state by defining some simple rules.
Simply put the necessary logic into a common owner of your two components (so one or more level up in the hierarchy).
I wanted to ask, looking from the 'best practices' side, which solution is better, getting a form data in Controller and passing it to Model, or retrieving it directly in the Model?
I use the first solution, which makes your controller methods very long and ugly, but I think it is still the right choice. But recently I have seen some other projects source code where the form data is retrieved in model, but it seems that it breaks the rule, where the model should not know, where the data comes from.
So which is the better practice?
As #lukasgeiter said in the Comments, I also say this would typically be done in the controller.
You may want to have a look at the corresponding laracasts on
MVC
Models
Controllers
Basically, you already said it. Models are just kind of "storage-interfaces" while Controllers are places, where the logic happens.
Also, have a look at MassAssigment, which cannot be done within the Model itsself but in the controller. This might be of interest in your case (without knowing the details).
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
As an MVC newb, I keep getting caught up in the details. One in particular is making me pause longer than I'd expect; pagination. Should pagination go in the model, or in the controller?
In case it matters, I'm using ZF, and would like to paginate the results of some SQL data.
Pagination separates records between pages, so it only gathers data from the model, but deals with presentation. Unless it's intrinsic of the model to split the output in multiple pages (which rarely occurs), my suggestion is to put pagination logic (IE dealing with page number) in the controller.
You might also want to consider taking advantage of a view helper, to minimize the code you put into your controller (fat controllers aren't a good thing).
The thing is though, that Zend_Paginator has a very convenient set of adapters. One of these is Zend_Paginator_Adapter_DbSelect which allows you to enclose a Zend_Db_Select query for efficiently paginating a sql query (e.g. limiting the results). So I can see why you are wondering where to construct these. Although you can indeed debate whether the model is the best place, I personally don't have a problem with creating a method in my model like:
public function fetchEntitiesAsPaginator();
... which would return a Zend_Paginator instance injected with a Zend_Paginator_Adapter_DbSelect.
BTW:
I personally don't consider a paginator just for presentation. I just consider it as a glorified LimitIterator. When you look at it from that perspective, things are starting to look a bit different already. And as a side note: the presentation concerns of Zend_Paginator are seperated by the Zend_View_Helper_PaginationControl view helper already anyway.
Logic to paginate goes in the controller. Any data you need, for example the current page number, should go in the model.
When in doubt, data goes in the model and everything that acts on the data goes in the controller.
The controller should handle the parameter for the page number, and then pass it to the model, which will then know which records to retrieve.
For example...
$userModel->getAll((int) $_GET['page']);
(I don't know Zend Framework, but the idea should be clear)
The framework I'm using on my project follows the MVC Pattern. I"M building JSON feeds and need to structure them in a different way then what the system gives me by default from the ORM. Where should I be handling the task of mangling and shaping my data that I'll serve up, in the model, view or controller?
Right now I'm doing it in my controller, then passing that data to the view. I can see this fitting better under the Model or the View but not sure which one.
If this different structure is only relevant to the view, you should keep it in the view.
If this structure is used in more than one view, make a Helper for it.
Internally your app should standardize on one data format, so models should always return a standardized format. If you were to do something with that data in your controller, you'd need to change the logic for interacting with the data just in that one controller function, which in this case doesn't make much sense. If you later decide to change the format in the model, you'd also need to change code in the controller that interacts with it. Don't create dependencies when there's no advantage to do so.
I'd write a model method to do it if I were you. Having it in the controller will make your controller fat, which is bad, and means you can't call that functionality from other controller actions or anywhere else. Although it could be considered presentation logic, I prefer to keep my views really simple with just conditionals and iterators at most. There may be an argument for having it in a helper, but I'd still stick with the model.