How to structure urls with backbone.js? - javascript

I'm building a ticketing system website in Backbone.js. I now need to get a collection of messages belonging to one ticket. At first I thought of the obvious route '/ticket/:id'. Unfortunately, this already returns the ticket itself (creation date and which supporter was assigned to it). For this reason I need a different route.
A second logical option would be '/message/:id', but of course this refers to the individual message of a certain id.
So my question is: which route or url would you think is logical (keeping in mind the Backbonejs way of doing things) for getting all messages belonging to a certain ticket id? All tips are welcome!

If you try to model a collection of messages belongs to a ticket, you should use:
/tickets/:id/messages/

Related

Creating Member Variables/datasets in Wix & javascript

I'm trying to create a credits system specific to a single user within my website with wix but I can't seem to find any way of associating a variable or dataset with a single account that can take away credits when used. Its my first time using wix and Im not sure if this is possible.
Tried currentMember.getmember() for which there was no reference on the velo page.
Since your question is quite general, I will give you a general answer.
The basic idea is to create a collection with a field that references one of the member collections. That will associate each item in your collection with a specific user. Then you can keep track of credits using your collection.

Inappropriate Redis Database Design

I have a node.js API that is responsible for 3 things:
Registering a buyer
Getting a buyer with ID
Finding the matching buyer's offer based on some criteria
Details here
Since I'm new to Redis, I started the implementation like this:
JSON.stringify the buyer and store it with SET
Store all buyer's offers as ordered set (this is for the third endpoint, which requires the offer with the highest value) - this set contains string that represents the name of a hash
Then, that hash stores strings that represent the names of sets that have certain values and a location which the user will be redirected to after these conditions have been fulfilled (buyer1_devices, buyer1_hours, etc.)
Now, here is the problem:
I need to get GET /route working. As described on GitHub page that I have provided, I have 3 parameters: a timestamp, devices, and states. I have to browse through all the sets and get the appropriate location to redirect a user to. The location is stored in a hash, but I have to browse through all the sets. Since this is probably a bad implementation, where did it all go wrong and to go about implementing this?
Note that this is a redis problem, not a node one. I need instructions on how to go about implementing this in Redis, and then I will be ready to code it in Node.
Thank you in advance
The first rule of Redis: store the data just like you want to read it.
To answer the /route query you need "filteration" on two attributes of from the buyers' offers - state and device. There is more than one way to skin that cat, so here's one: use many Sorted Sets for the offers.
Each such offers Sorted Set key name could look like this: <device>:<state> (so the example offered in the git will be added to the key desktop:CA).
To query, use the route's arguments to compose your key's name, then proceed regularly to find the highest-scored offer and resolve the buyer's details in the Hash.
Now go get that job!

How to validate read and secure documents in CouchDB?

In 10 Common Misconceptions about CouchDB, Joan Touzet is asked (30:16) if CouchDB will have a way to secure/validate reads on specific documents and/or specific fields of a document.
Joan says that if someone has access to the database, he/she can access all documents in that database.
So she says that there are a few ways to accomplish that:
(30:55) Cloudant was working on field level security access. Have they implemented it yet? Is it open-sourced?
(32:10) You should create separate document in a separate database.
(32:20) Filtered replications. She mentions that it slows 'things' down. She means that the filter slows the replication, correct?
Also, according to rcouch wiki (https://github.com/rcouch/rcouch/wiki/Validate-documents-on-read), it implements a validate_doc_read function (I haven't tested it, though). Does CouchDB has anything like it?
As far as I can see, the best approach is to model the database according to my problem (one database for this, another for that, one for this person, another for that person) and do filtered replications when necessary. Any suggestions?

Should I use one publish per collection or several?

I am working on a user group system. Each group has several features and I want to make the interaction with the group collection as secure and simple as it can be since it is still at an early stage.
Right now, I have a group section in my website where I use several nested pages. The purpose of the section is to allow the user to get in a group, request membership if the group is private, browse one group objects, etc.
For example, within my group section, I can load in the yield a "see all groups" page, a "create a new group" page or "see only my groups" (the ones I am member of) or a "view group" to get a group details.
My first approach was to create one controller.js file for each subpage, which call one subscription tailored for the subpage needs. For instance, I have an 'all_group' publication/subscription for the "see all groups" subpage and a "my_groups" one for the "see only my groups" subpage.
But this is becoming really messy. Additionally, I declared my "group" collection in the both folder, so I am not sure to follow where the data available to the client comes from.
Now that I explained the situation, here are my questions:
when I do a console.table(Groups.find().fetch()); on client, I see fields that shouldn't be there (i.e. not returned by my current publication or any other). Is that because I declared the "group" collection on client side? How to fix that?
Should I get rid of all these publications and create only one with everything the client is allowed to see? I would then subscribe to it from the group section page controller and work with a single set of data.
Should I simply block any insert/update/remove from client with allow/deny rules and make these using methods only?
Would it be safe/advised to put my methods in both folder so I don't lose the latency compensation feature?
EDIT
Ok, I was freaking out because I had all my collection data on client-side but it was just a bad query in the publish (I was using both field:1 and field:0 projections).
Two questions remain:
If I use methods, I assume I don't have to deny everything in the native driver, I just have to be more restrictive than what method allow, right?
If I put my methods in the both folder, it will be executed both on client and server, so in "client offline" context, even if the client mess with my methods, the server should roll back the changes if the client result is different than his (assuming that the changes couldn't be done using the allow-deny rules)? And I will have latency compensation working even with the methods?
To better control and visualize your subscriptions, you can use msavin:mongol.
Creating one catch-all publication is not a good idea performance-wise (sending all data to all clients will be a pain to everyone involved).
If you use methods and have removed autopublish, then yes everything is denied... Except for updates on the user's own profile. You may want to manually deny that too.
With methods and collection rules you should share the validation code. This way, client and server validate the same way (and should always come up with the same results), so unless your client is screwing up with the console there should be no issue and lag compensation should remain.
If your server method does something the client should not know about, you can also define the method once on the server, and once on the client. Same effect.

Exposing server-side state through client-side controls in ASP.net

Hopefully this isn't a redundant question--I'm not really sure how to word it. Let's say I have a list of items on an ASP.net page. That list is selectable in that whenever the user clicks on one, the page does a postback and the server code stores the index or some unique identifier of the picture in a ViewState property indicating that it is currently selected.
I would like to minimize the load on the server and therefore I would like to store the index or unique identifier representing the image in some way on the client side. The best way I can think to do this is to store said information in a hidden field ), however I had two questions about this before I go crazy:
Is this a security risk in any way, shape or form (i.e., exposing implementation details of the page)?
Is there a better/best way to do this that is more industry-standard? Does ASP.net provide a framework to do this that is cleaner than my idea? Seems like this would be a fairly common requirement to me...
I have been working in ASP.net for about two years now. Please, be kind :-)
Best,
Patrick Kozub
The only security risk would be if some list items must remain non-selectable. It sounds like that is not the case in your situation. The user already knows the information, because he or she already selected the item.
NOTE: If the server ever does anything with that information and pulls it back from the user, then you must validate the index value. Otherwise, the user could change it to an invalid index, such as (-2), and trigger an exception.
You can store the index (or related value) in a global javascript variable. If you're avoiding a trip back to the server, .NET doesn't really have a role to play.

Categories