Please note, I'm not asking you to give me a code solution, but I would like to know the best approach, how I can display a preview of images and videos that I have selected with a post, before saving the post.
My relational database would have a post table, that stores the text of the post, and a files table, that stores all the files. The files should be associated with a post.
When I use input type="file" tag, and then select files, I will only get back the file name, not the path where the file is located on the filesystem. The path won't be provided by the browser, due to security reasons. But without knowing, where the selected files are located on the filesystem, I can't display them.
So the only thing I can do, is upload the files first. But the files will not be associated with the post, as the files are uploaded, before I have actually saved the post. So the post does not have an id yet, to which the uploaded images or videos can be associated with.
So what would be the best way, to solve this puzzle? Obviously the best way would be to upload the images, only after the post was saved.
Is there a way in AngularDart, to display a preview of images and videos on the filesystem, and then only upload them, once the post has been saved?
If not, what would be the best approach to this?
The only other option I see is to save an "empty" post, just when it is created to get the id, and then upload the files to the post, that will have an id, because it has been saved already. But that would use much more server side resources and if the user cancels the post, the images will have to be deleted from the server again.
I hope my question makes sense...
Related
I'm working on an intranet for a school, I would like to set up online folders for students, some kind of Google Drive-ish folder, one for each class.
So far, I managed to create it, but I would like to add some improvements.
Basically, each Class has many Resources, and each Resource has an attached file (with Paperclip). So, for now, I'm using Dropzone, and each time a student uplaods a file, it works just fine, but other student have to refresh to see the file.
I was wondering if there was a way to upload resources in real-time, so that everytime a student uploads a file, all other students can see it appear as soon as it is uploaded.
I searched for a bit, on one hand, I have the Publish/Subscribe which appears to bring some kind of realtime, but only for messengers-like applications, and on the other hand, I got some gems, like Remotipart, which allow to upload files asynchronously.
Is there a way to combine both ?
I'm using RoR 4
By using Remotipart, only the student who uploads the document can see the uploaded data & no other students can see it. You can do a patch by polling.Hit a Ajax request after few seconds which will fetch the data from the server & append it on the HTML
In my application, I have a textarea input where users can type a note.
When they click Save, there is an AJAX call to Web Api that saves the note to the database.
I would like for users to be able to attach multiple files to this note (Gmail style) before saving the Note. It would be nice if the upload could start as soon as attached, before saving the note.
What is the best strategy for this?
P.S. I can't use jQuery fineuploader plugin or anything like that because I need to give the files unique names on the server before uploading them to Azure.
Is what I'm trying to do possible, or do I have to make the whole 'Note' a normal form post instead of an API call?
Thanks!
This approach is file-based, but you can apply the same logic to Azure Blob Storage containers if you wish.
What I normally do is give the user a unique GUID when they GET the AddNote page. I create a folder called:
C:\TemporaryUploads\UNIQUE-USER-GUID\
Then any files the user uploads at this stage get assigned to this folder:
C:\TemporaryUploads\UNIQUE-USER-GUID\file1.txt
C:\TemporaryUploads\UNIQUE-USER-GUID\file2.txt
C:\TemporaryUploads\UNIQUE-USER-GUID\file3.txt
When the user does a POST and I have confirmed that all validation has passed, I simply copy the files to the completed folder, with the newly generated note ID:
C:\NodeUploads\Note-100001\file1.txt
Then delete the C:\TemporaryUploads\UNIQUE-USER-GUID folder
Cleaning Up
Now. That's all well and good for users who actually go ahead and save a note, but what about the ones who uploaded a file and closed the browser? There are two options at this stage:
Have a background service clean up these files on a scheduled basis. Daily, weekly, etc. This should be a job for Azure's Web Jobs
Clean up the old files via the web app each time a new note is saved. Not a great approach as you're doing File IO when there are potentially no files to delete
Building on RGraham's answer, here's another approach you could take:
Create a blob container for storing note attachments. Let's call it note-attachments.
When the user comes to the screen of creating a note, assign a GUID to the note.
When user uploads the file, you just prefix the file name with this note id. So if a user uploads a file say file1.txt, it gets saved into blob storage as note-attachments/{note id}/file1.txt.
Depending on your requirement, once you save the note, you may move this blob to another blob container or keep it here only. Since the blob has note id in its name, searching for attachments for a note is easy.
For uploading files, I would recommend doing it directly from the browser to blob storage making use of AJAX, CORS and Shared Access Signature. This way you will avoid data going through your servers. You may find these blog posts useful:
Revisiting Windows Azure Shared Access Signature
Windows Azure Storage and Cross-Origin Resource Sharing (CORS) – Lets Have Some Fun
I have a project where I have several content types (Article, Interview, etc) with nested images. To handle the images, what I did was implement a popup 'image upload' box (using a combination of Paperclip and Uploadify) so the user can upload an image immediately to the article.
The process works like this: the user clicks the 'upload an image' icon, then a box pops up where they can add paperclip file upload fields to upload as many images as they want. Uploadify instantly uploads the photos and assigns them the article ID number they're attached to. Then the photo's HTML gets sent to the WYSIWYG editor. If they want to delete photos as well, they can. If it sounds like WordPress, that's what it's based on.
Anyway, I have this working great. Photos remain associated and attached with their respective articles, as opposed to throwing everything in one huge folder (like many WYSIWYG image uploaders do) where anyone can add/delete anything.
But there is one little flaw to this...as I said, the image is assigned the content's ID number when an upload is performed. Well, you can see how this is an issue when creating a brand new article, as a new article doesn't have an ID number before saving it. So the image upload fails. Thus, this whole process only works on the 'edit/update' action.
In the interim, I told the team to make sure to SAVE the article first, then when they go back to edit it they can then upload their images to the body. But naturally, they forget as it's an easy thing to do, and as this is very user-unfriendly, I gotta solve this.
I see two ways I can go about this.
Assign an ID (hidden field or otherwise) to an article on the 'new' form. This would appease the uploader as it fills the 'nil' value it errors out on, then when the article gets saved the first time, it would assign it that very same number. But I see a potential issue...what if another user creates an article at the same time and the database assigns it an identical ID number?
I noticed that the moment you create a new WordPress document, the new document 'autosaves' immediately as a draft. So my line of thinking is this...when the user goes to create a new document, the 'new' action would actually trigger a 'save' operation, bypass any validation errors (since the fields are blank), then immediately redirect to the 'edit' action. That way, the ID is saved and everything would work as normal, and the entire process may look seamless to the user.
How would you handle this situation? Like I suggested above, or is there an even better way?
I decided to go the second route and perform a save on the new action and bypassing the validations, then redirecting to the edit form, throwing as "autosaved" flash message in for good measure. It works well.
I have a head aching problem that I can't seem to find an easy solution to.
I have a couple of models, each with an image attachment, that belongs to a user. I have made a very nice ajax file upload and image cropping form, but there is a problem. Everything works fine when I am editing objects that is already in the database but when I upload a file as I create a new object it doesn't. The thing is, to be able to upload and save the image, the object already has to be in the database. I have found two possible solutions to this problem but none of them will work properly.
The first one is to create the object in the database in the new action and redirect to edit action. The pros is that it is a very simple fix. The cons is that the objects will show up in the list with previously created ones even if the user canceled or never submitted the form, which is very confusing.
The second possible solution is to lift out the attachment fields of the model to a separate model. On creation I would then only need to create an attachment object. If the user canceled it would leave the attachment orphaned, but that is probably okay as the orphans could be cleared periodically. The problem with this is that I can't find a way to prevent users from hijacking the orphaned images, or any other image for that sake. Unless I cant solve this problem I'm stuck.
I'm all out of ideas and would really need some help on this one.
Thanks, godisemo
EDIT:
I was probably unclear. In my form it is possible to upload an image. The image is uploaded instantly to the server with javascript, before the form is submitted. The reason is that I want to allow the users to crop the image. This is no problem wen working with existing objects but it is when creating new ones, as I tried to explain earlier.
I've never had to have the model already in the db for paperclip to work.
One thing you can try though is the following. I don't know what your model is called but let's say User has an image. Make your new form so that all of your user fields are passed in the params[:user] var, but then make your image upload file separate from params[:user], say params[:my_image].
Then in your controller validate and save the user, then after user.save, attach the image.
I solved the problem now, with a completly different approach. Instead of thinking databases, objects and models I solved it using file system and temporary files. When the image is uploaded it is processed by paperclip, I then move the generated images to a folder where I have control over them.
I based my solution on a really great article which you can find here, http://ryantownsend.co.uk/articles/storing-paperclip-file-uploads-when-validation-fails.html
So, I'm working on an app where users can upload and manage photos with a bunch of industry specific metadata attached to them.
The Photo model has all this metadata in it, and I'm using Paperclip to attach the actual image file to the model and store the images on Amazon S3.
The user interaction currently works like this:
A user clicks "Add Photo" and is taken to the "New Photo" page where he is presented a form.
The first thing on the form is a file chooser. The user selects a file.
Beneath this are several different fields of metadata for the user to fill out, so the user fills these out.
The user hits submit, the file uploads and a new Photo object is created, the user is redirected to a different page.
So, the obvious improvement that I'd like to make is for the photo to actually upload at the beginning of this process so that there isn't such a noticeable delay between hitting submit and being redirected to the next page. It would also be nice to be able to show the user a thumbnail preview of their photo once it's done uploading, so that they can see the photo they're putting in metadata about as they fill in the form.
I figure I could make that happen if I split the image file into its own model, but I'd then be referring to the images like so:
#photo.attachment.file.url instead of the simpler #photo.file.url that I use now. I'd rather not "nest it" more deeply than I have to.
Also, splitting it into two models raises the issue of managing orphans, which I currently don't have to deal with.
So my questions are:
Is there a good way - preferably not using Flash - to create this asynchronous upload behavior without splitting into two models, OR --
If I must split the metadata and the file into two models, is there a way to get Paperclip to treat an attachment as its own model so that I can access it using <modelname>.<paperclip_method> instead of <model_name>.<attachment_attribute>.<paperclip_method>?
I know that's a big question, so thank you very much in advance for your help!
I'd recommend that you replace the new action with an edit action (you can auto-create a photo model when the user selects the action. This way, you can use an AJAX file upload (supported in some modern browsers) with a Flash fallback for doing the upload, and also edit the metadata. For doing the upload, try looking at plupload or uploadify.
What's wrong with simply defining Photo#url like so?
class Photo
def url(*args)
attachment.url(*args)
end
end
No need to get fancy here.
After a week of experimentation I just thought I'd post what I finally did:
I did in fact split the photo into two models, because I ended up having to create empty records with any approach I tried. I found it was easier in the end to have two seperate models because:
It made it easier to work within Rails convention (use the standard REST actions for the second model to handle asynchronous updates, rather than having to add several custom actions to the parent model).
No matter which option I tried I ended up having orphan records as a possibility. I found it was easier to have a parent object which does not ever save unless valid (the Photo model in my case), and to have attachments which may be orphans. The attachments are never called directly anywhere in the app, so there's no risk of accidentally having an empty record being pulled up, and no need to set a default scope or something in order to only show "valid" photos. Cleaning up orphans is pretty easy, just do Attachment.where( :parent_id => nil ) and delete all those.
I can maintain the previous code by simply delegating attachment to photo. See this answer on another question.
I hope this saves others some trouble down the road. If you need Ajax functionality with attachments it is best to make them their own model. Also, for adding ajax file upload to forms, check out https://github.com/formasfunction/remotipart. This saved my app.
Just wondering, are you not setting the dependent clause on your association? For example,
Class Photo < ActiveRecord::Base
:has_one :attachment, :dependent => :destroy
end
This will prevent orphan records, as anytime a destroy method is called on Photo, it'll first do Photo.attachment.destroy. It works with :has_many as well.
Basically, you're splitting up the creation of the Photo object into two parts: uploading the photo, and adding the meta-data. In a non-AJAX site, this would be two separate steps on two separate pages.
What I would do is allow the AJAX upload to instantiate a Photo object, and save it (with the uploaded photo). I would then have the AJAX code return a token to the site that corresponds to a session variable to let the form know the record for the photo has already been created. When the user submits the rest of the form, if the token is present, it will know to populate the data on the already created photo object. If the token is not present, it will know it needs to create the Photo object from scratch.