I'm wondering if it's possible to use Filter Functions when requesting a view something like:
http://localhost:5984/db/myView/myMap?filter=myFilter.
I'm going to use Complex Keys with separate views eventually but I'm wondering if this is possible. So far I tried but it's not showing me any differences.
According to the documentation it's not possible to do so. You can pass keys to query your view but you can't filter it. Filter can be applied to _changes aswell as in replications.
Related
I have some data on a model that comes in the form of a code such as "US60" and "US70".
I need to take that value and show a display value such as "US 7day/60hour" and "US 8day/70hour". I'm not sure if there is any best practices way to do this in Angular, and I'm not having much luck googling it.
What I would do is have a service that I pass in type and value, and it would return a display value, but as with many things in Angular, since this is my first Angular project, I don't know if it's a good way to do it or not.
I'm just needing to use the display value in html such as {{settings.cycle}} I am already able to access the variable, but I want to show the display value, not the actual value.
If I am getting the gist of your question correctly, you have the value available but want to alter how it is displayed on screen right?
There are two main approaches to do this in Angular, using a directive or a filter.
A filter is basically like a pipe in Unix. You can alter a value before it is being displayed. For example:
{ username | uppercase } will transform the username into an all-caps username. Naturally, you can define your own filters for your use case. Filters are mostly used to transform single values. So for your case, a filter sounds best.
A directive is commonly used to create entire components on a page. For example: <user-profile-card></user-profile-card> would be transformed, using the directive, into the appropriate html/css/logic. So these are used often for larger transformations which involve logic, like server requests. Still these directives could also be used for very small components.
So for your case, although what you are actually want to do is not completely clear to me honestly, a filter seems to be your best shot ;)
I am using ng-repeat to render a complex set of data in the UI. After receiving the data, I need to filter the data based on some checkboxes, sliders etc. Right now I will have 6 custom filters, based on time, price, and some checkboxes. I am using them like following
ng:repeat="response in searchResponse|filter:filter1(response)|filter:filter2(response)|filter:filter3(response)|filter:filter4(response)|filter:filter5(response)|filter:filter6(response)|limitTo:totalDisplayed
This works fine but I think this is a very expensive way of applying filters. I have noticed a considerable lag in performance in rendering after this. Is there a better way to handle filters here ? Considering the fact that I may have more such filters in future.
Please suggest. Thanks !
Instead of chaining filters, why not something like:
ng:repeat="response in searchResponse|filter:genericFilter(response, filterConditions)|limitTo:totalDisplayed
What you're doing is like chaining filters one after another, and that may not necessarily be needed – one filter that selects out the results based on filterConditions
I have models with the the following relations, defining a situation where users can belong to many groups, and multiple groups can be granted access to a project.
User HABTM Group HABTM Project
I would like to set things up so that any find() done on the Project model will only return results to which the current user has access, based on her group membership.
My first thought is to use the beforeFind() callback to modify the query. However, the two-level association has me stumped. I solved a similar problem (see this question) by rebinding models. However, that was for a custom find method—I don't think that approach will work in a general situation like this where I need to modify arbitrary queries.
Using afterFind() to filter results isn't a good idea because it will confuse pagination (for example) when it doesn't return the right number of records.
Finally, I have a nagging suspicion that I'm trying to re-invent the wheel. The access control I've seen in CakePHP (e.g. Cake ACLs) has been at the controller/action level rather than at the model/record level, but I feel like this should be a solved problem.
Edit: I eventually decided that this was over-complicated and just added a getAccessibleByUser($id) method to my Project model. However, I'm still curious whether it's possible to globally add this kind of restriction to all find() operations. It seems like exactly the sort of thing you'd want to do in beforeFind(), and I suspect (as DavidYell suggests below) that the answer may lie with the Containable behavior.
You should look at the Containable behaviour. If you are using CakePHP 2.x then it comes in the box.
This behaviour allows you to manage the model relations and the data which is returned by them, along with allowing you to pass conditions, such as a group_id into your contain.
http://book.cakephp.org/2.0/en/core-libraries/behaviors/containable.html
It seems that AngularJS really puts an heavy emphasis on using filters and other ng directive in your view to filter and sort your data, instead of doing it manually in the model. Is there any reason for that, ie is it faster, cached, or something?
I want to show a list sorted for example, but I also want to access the sorted list for other purposes that are not view related. It's very easy if the list is directly sorted in the model, so I'm trying to understand if there is a drawback to doing it this way.
Thanks!
I don't see anything wrong with pre-sorting the data if it makes sense to you but here are some pros and cons for using Angular filters.
Pros:
Clear separation of the view and model. The model/controller does not need to be aware of or include code related to how the data will be displayed/sorted/filtered
Since filters are executed as the model changes the orderBy filter can automatically sort as items are added to an array via the UI
Filters can be used to format data for display (the currency filter for instance) as well as modify the DOM adding/removing items (the filter filter for instance) without modifying the underlying model data
Promotes reuse of commonly used built in or custom filter functions
Cons:
Poorly written filter function can cause performance issues. You can see a purposely contrived example in the AngularJS Batarang video starting at 4:30. Any code (not just a filter) can be written poorly but it's not initially obvious how often a filter gets called.
Slightly confusing in that some filters act on a single number/string (currency filter) and some on arrays (orderBy filter)
Syntax to pass arguments and chaining of filters can also be a bit confusing
I'm sure there are many more pros/cons but hopefully this helps!
right now I have controllers/actions that do standard retrieval of model/associated model data. My actions currently just pass the variables to the views to pick and choose which values to display to the user via HTML.
I want to extend and reuse these functions for the case where a mobile device is making a call to grab the JSON format version of the data. I am using Router:parseExtensions("json") and that all works fine.
My main question is how to handle data size. Right now even a User model has many, many associated models and recursive relationships. As of now I am not using contain to cut out the unnecessary data before I pass it to the view, b/c the view will take the elements it wants and it won't affect the HTML size.
But for my JSON views, I just format it and return the whole thing, which makes it extremely large. My current thought process is I just need to case it to use containable in the case of JSON, but I was hoping there was a more elegant solution? Or is this the cakey way to do it?
Thanks!
Actually, using containable and fine tuning your query is a very elegant solution. Even if your view does not use the actual data, you put unnecessary load on your database by adding data / joins you don't need.
Try and limit your query and relations by using both Containable and fine tuning the relationships in your models and paginator calls.
It is also recommended that you move most of your find calls to the model layer. They will be re-usable, easier to test and overall more Cake-ish.