Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Im currently building a web app based in firebase and want users the ability to create and join game rooms. Currently i am having an issue trying to figure out how to create the room where others can join. I was wondering if anyone can help me get started on this issue. Just an FYI each user who will be creating and joining the room will have their own account with unique ID if that matters
Firebase doesn't have any concept of rooms. There are parent and child nodes which are code wise handled through key: value pairs, very similar to a Dictionary.
There are also no users in Firebase either, other than the user id's (uid) and associated data that are created when new user is created in Firebase and stored internally on the server. That data is used for authentication. If other data needs to be stored about a user, a name perhaps, it's done within the database itself.
Keeping it simple, let's say we want to store information about users and rooms.
users
uid_0
name: "Bill"
uid_1
name: "Ted"
uid_27
name: "The Doctor"
The uid's are the ones that are created when a new user creates an account in Firebase. Your app will collect the uid that Firebase provides and write it and any other user data to the users node; in this case the users name.
Then the rooms
rooms
room_0
room_name: "Phone Booth"
description: "Time travelling in style; Excellent!"
uid_0: true
uid_1: true
room_1
room_name: "Tardis"
description: "It's bigger on the inside"
uid_27: true
In this case room_0, the Phone Booth, has both Bill and Ted in it and room_1 has The Doctor in it.
This is not the only way to structure the data and your structure may vary from this a lot, but it's a place to start.
Note: key names should almost always be created with push(). I used room_0 etc as a placeholder. Best practice is to disassociate main parent key names from the data it contains. i.e. don't hard code key names with something like an email address - that's bad news.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 17 hours ago.
Improve this question
I always had this doubt when I think about user data. If I created a site, for example a marketplace, when I'm going to store the data in the backend should I simply create a big array like this?
const user = [
userName: "john",
userWallet: 122,
userProfilePic: "https://blbabablabl.com/ewxase"
userCart: [
{
productName: "Air Jordan 1",
price: 280,
productImage: https://www.blablabla.com/image
}
{
productName: "Louis Vuitton Bag",
price: 900,
productImage: https://www.blablabla.com/image
}
...
]
]
and then for every user I create an array?
is this right?
what companies do in this situation?
where can I learn more about storing things in the backend?
I'm really lost when it comes to backend.
(I'm using firebase in my project cuz I don't have the interest to study back-end. For now, I'm focusing more on the front-end)
For smaller use cases, you can definitely use arrays. However, this isn't scalable - you'll find that this approach can become very inefficient as your user base grows. Most companies store their user data in a database, such as MongoDB or MySQL. Databases allow you to create a "users" collection with columns for each of the attributes such as username, wallet, profile pic, etc. For more additional info about databases: https://www.w3schools.in/sql/database-concepts
The best way to do that would be to create separate sub-collection name carts under document of given user and store all necessary attributes for each cart item as document of that subcollection.
eg. You have user documents under users collection, then
cart document path would be as /users/3y1x1Dy6FYOGnSW0Sa4f1EUhiIo1/carts/WADVd2AZ91d7m9kSq3GP
See screenshots below:
Alternatively, you can create same level collection for carts and store userId field on cart's document.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm Making a website for a friend where people will submit stories. These will be short stories, presented on the website with a Title, a "by" section, ideally a picture of the author, and finally the story.
Now I've already got the design of the site up, but this is partly because I know how to use HTML and CSS. Though I know a bit of Jquery, Javascript, PHP, and SQL, I'm at a loss for how I should be saving any of the files and displaying them.
Assuming I want the website to automatically take in any stories, what is the best way to go about doing this? Right now, we have a contact form that would connect to our email where the stories can be sent it... is there a better way to do this so we can somehow just approve the story, then save the story somewhere, then have the website grab the story from where all stories are saved, and finally display it on the website?
If there's any hints or things I can look into that would help me accomplish all of this, I would greatly appreciate it!
Thanks in advance!
There is no quick and simple answer for this.
You need to store user-submitted data somewhere - preferrably a database.
You could try to start with an SQL database like SQLite or MySQL.
These databases hold tables that can stores values - values your users submitted
Example: Stories Table
story_id | author | img | story_text |
-----------+--------------+-------------+--------------------+
1 | john | john.jpg | I bought candy. |
2 | mary | mary.jpg | my pony died! :( |
author, img, and story_text would be values sent to the server from an input form on the website.
The server's language (ie, php) would take these values and store them in the database, something like this
$st = $db->prepare("INSERT INTO stories_table (author, img, story_text ) values ( 'john', 'john.jpg', 'I bought candy'. )");
$st->execute();
Hopefully you can see how the above line would store things in the table i drew above.
Unfortunately It's nothing something that can be answered here. It's something that requires a whole book. (don't forget you also need to use PHP to grab form values that the user inputted), but hopefully this gives you an idea of one of the ways it can be done
For s*** and giggles, here's an inefficient way of doing it without a database - using a text file instead.
* Step 1 *
Learn how to grab form values with PHP. Endless tutorials on google.
* Step 2 *
In your server, create a file called stories.json.
Then, when a user submits a form, you can use PHP to append values to to stories.json. Let's say i submit a story. stories.json would look like this
{
"author": "sqram",
"image": "sqram.jpg",
"story": "Today, I worked."
}
Now you have used PHP to store the information in a file, and can retrieve that information however you want. You could ajax it with javascript and show my story. that stories.json file is essentially being a database for you.
I don't recommend doing it this way. In fact, not a single person will. But it's an actual way of doing.
What you're looking for is to use PHP and MySQL with a database. What you want to do is why PHP and MySQL are a thing.
Have a database where the stories are stored, and there will be a column with if the story is approved or not. If you approve the story then it will display.
(This is just a rough overview of what you'll need to code.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
I'm drawing a communication diagram for an application where you can buy books. I'm using domain driven design and have a 'shop' object, a 'cart' object, a 'book' object.
My first communication diagram, for when the user first comes to the site, is straight forward. I generate all html (to show all books and an empty cart) back end with the help of php. I use an MVC pattern; so first I send a message to a 'controller' which creates a 'shop' with 'book's and an empty 'cart' before sending these to the view.
My second communication diagram is where I run into problem: It is about adding a book from the shop to the cart. I already have all the information I need to add the book to the 'cart' on the client side; since all book information is already in the shop. So when writing the communication diagram, should my first message, i.e. AddBookToCart(bookId:int), be to a JavaScript object called 'shop' which gets the book info and send a message 'AddBookToCart(bookinfo:object) to 'cart' which in turn update the page?
I have never done communication diagrams with JavaScript in mind before so I'm really confused about how to deal with the front end.
(I have been searching for over 5 hours but find nothing on this topic. It's like it's not even an issue to people. Am I viewing this problem completely wrong? Otherwise any resources, or even search terms to use to learn about how to model (and code) these kind of things would be much appreciated)
In UML there are strict diagrams, as Classes, Packages, Data; and non-strict ones. A communication diagram belong to the last. You can set your own rules about what and how to show there. Any advice would be of the style type.
I would first create the component diagram, to divide different levels of architecture, and only after that turn to communication diagrams. If you would need help again, please, publish here the appropriate component diagram for us to understand what you are talking about.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm implementing a small voting system on my website. I came up with three implementation methods that I would like your feedback on.
I want to give my users the ability to cast several types of votes on some user generated content. It's micro Q&A about games, not unlike SO's and their vote system, on a much smaller and specialized scale.
After toying with the following methods I can't decide which is best.
Method 1: Uses URL params and forms
Method 2: Uses URL params and jQuery
Method 3: Uses ether one of the above, but retrieves its info from the database
The schema assumes both Q's and A's are a post object with a different postTypeId, and the following two tables:
voteTypes(id, voteTypeId, voteName)
votes(id, postId, parentId, userId, ownerUserId, voteTypeId)
parentId represents the id of the
parent post. If the post being voted
on is an answer post, it is used to
ensure a question post (postTypeId=1)
can have only one accepted answer.
ownerUserId represents the userId of
the post's (being vote on) owner. It
is compared against the userId, which
comes from the session, to ensure a
user can't vote on his or her own
posts.
userId comes from the session and represents the person casting the
vote.
Method 1 Create a vote form in the view as the query loops over each post. Use hidden fields to capture the data:
<input type="hidden" value="#voteTypeId" etc...
The postId, parentId, and ownerUserId will come from the query being output to the view. The userId will come from the session.
Disadvantages:
1. Users can manipulate data. A user can accept an answer to a question he did not ask since ownerUserId is set at the view level.
2. Cumbersome: I would have to create as many forms as there are posts in the view. Each post will have 4 forms. A page with 10 posts can have 40 forms.
Advantages:
1. It's simple.
Method 2 Use anchors with custom data tags and jQuery to construct the vote URL.
<a data-vote-type-id="#voteTypeId" data-post-id="#postId" etc...
The ownerUserId, postId, parentId, voteTypeId will come from the URL. The userId from the session.
Advantages
1. Light weight and no forms. One jQuery call to submit any vote, as such:
var data = 'voteTypeId='$(this).data("vote-type-id") etc. Submitted over ajax!
Disadvantages:
1. JS disabled = no vote.
2. Data can be manipulated since it's being sent through the URL.
Method 3 Submit only the voteTypeId and the postId over URL, using either methods 1 or 2. Use the postId to query the db and verify the post object being voted on exists. This way I can also verify the ownerUserId and parentId of the post.
If the post is an object, create a newVote object.
The userId will come from the session. The postId and voteTypeId will come from the URL.
The parentId and ownerUserId will come from the post object I queried for.
Advantages:
1. Data shielded from user manipulation as the presence of the post can be verified, and so can be it's ownerUserId and parentId.
Disadvantages:
1. Laborious. Asking the database to find the post and retrieve details already available at the view level seems unnecessary.
2. The data is denormalized in some instances, so after a successful vote (an up vote, for example) I have to increment the posts table via object callbacks (add +1 to the existing number of up votes, for example), which is yet another call to the database with information that was already available at the view, and then the controller levels.
Other things I have not considered:
1. Finding if a vote already exists and toggling it, which will require yet another query. 2. Validation combinations are a nightmare.
I'm looking for feedback or additional ideas. So please share!
Many thanks!
I'd go with Method 2, but with some changes.
Server side
Hooks for casting a vote, changing a vote etc. those return simply true or false depending on the success.
Input PostID, VoteTypeID, UserID etc. you can't leave this out, if this is your bottleneck rethink the database model (if you can't fit it into a relational DB use noSQL stuff).
If you leave validation out, I'm gonna personally down rank your site into oblivion, do server side validation.
ALWAYS.
Client side
The Client gets the information from the view, then it can issue the specific calls to the server, we assume a non-malicious user here, if that's not the case he will simply fail at the back end.
As soon as someone casts/toggles we do the following things:
Check whether this action is possible by using the data available in the view
Update the UI to reflect the change
Send the request to the server
If that request returns false we undo the action and give an error message
Benefits of this approach:
Security, I can't do impossible things just by sending some http requests
Users get a fast response and a decent feedback on errors
Since errors are unlikely to occur for non-malicious users we don't need endless amounts of checks here
Malicious users, well there fault if the UI fails, we don't care out backend is secure.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I'm trying to develop a stackoverflow.com widget for Mac OS X and I'd like to show the flair for a given username.
The different possibilities described in User Flair are all expecting the ID of a user but I'd like to let the user enter a username instead.
Is there any way to retrieve the userID for a given username?
Better yet, is there some AJAX usersearch callback that would suggest completions after parts of the username have been entered?
I dont think it is available. I had the same issue when I developed an wordpress sidebar widget. May be we can expect it soon ;-)
This won't be possible. At best, you'll get a list of userIDs that have the given username, because usernames are not unique, as I've demonstrated by changing mine (temporarily) to Huxi.
You could ask for a username + email address, do a search for the username using the users filter:
http://stackoverflow.com/users/filter/huxi
Then MD5 the email address and match to the Gravatars, and you have your userID.
This will work maybe 90% of the time. It will NOT work, however, when the username is common (the "API" will return at most 35 possibilities), or when the user has not provided an email address to StackOverflow. With these limitations in mind, it's probably easier just to ask the user to locate their ID themselves.