First, I do not know what I should understand when we talk about "dynamic images"... but in my website (talk about movies - www.mananaseguro.com) I have to display the poster of each movie. So I think these images are considered dynamic images.
I do not know:
If these images should be in the cache, and if yes what expiration date (GAE)?
If these images should be in the public folder (GWT)?
How to correctly refer to these images, I use setUrl("./MananaSeguro/posters/p1.gif") (GWT)?
If my APPLICATION_SPRITE (that have all UI images) be in the cache (GAE)?
I do not like to have all these images in ./client/resources/ directory. Is it possible to have them in the WAR directory to be more conformtable (if yes, how to configure it)?
After that, I will use OBJECTIFY for my database, but the same kind of question occurs :
Do you know in wich directory would I need to store these images (I will need to refer to their path inside the database)?
I do not know GAE, but do you know if there is an interesting feature to store these images (Blobstore)?
Not sure if you're talking about Google memcache service or browser cache. The images should be stored in the browser cache (the required headers will be set by the image service when the images are served). The images should not be stored in the memcache service, that's for storing data that is fetched regularly and/or is expensive to fetch or calculate.
The public (I assume you mean "war"?) folder is for static content, not dynamic. You'd need to re-deploy your application each time a movie was added if you stored movie images here.
The Images service generates serving URLs from blobstore keys. These are the URLs you pass to setUrl on the client.
The application sprite image should go in the public folder as it's static.
This page describes how to specify which files/paths should be served statically from the WAR
The dynamic images will be stored in the blobstore, so you just need to keep the blobstore key to retrieve them
Yes the blobstore is what you're after. With the Images API doing a lot of the "heavy lifting" for you.
Related
I'm trying to build a E-commerce site with a admin page where the administrator can upload images of certain products.
I'd like Meteor to upload those images to a folder and then display those images in the product page of that product.
I know that normally the image files that the client will be using should be inside the 'public' folder, but I'd like to know more about what other options I might have.
Also, if I upload a new file to the 'public' folder or if I delete a file in the 'public' folder, the website refreshes itself...and this is good and bad at the same time depending on what effect you are after....
Here are my questions:
What if I create a 'uploads' folder in the server and upload the images to that folder. Would it be possible to display the images inside the 'uploads' folder in the client browser??? How??
Is there a way to use the browser to access the contents of the 'public' folder???
Is there a way to stop the 'reactivity' of the site if changes happen in the 'uploads' folder created?
Is uploading the images to the 'public' folder the best solution available to this problem?
Thank you very much for the help
When dealing with what will likely be a large number of images I like to offload not only the storage but also the processing to a third party.
My go-to app in this situation would be Cloudinary. Here's why:
Storage - I can store the original images outside of my application. A huge benefit to keep images in sync from dev to prod.
CDN - I get the extra benefits of images being quickly loaded from the Cloudinary CDN.
Off-load Processing - All of the processing of images is handled by Cloudinary which doesn't slow down my app as a whole.
Image Manipulation - I can make calls to the original image, calls to just get a thumbnail, and calls to change manipulate, ie :effect => grayscale. So if a 1000x1000px image was uploaded, I can request a 50x50px from Cloudinary that will return the image cropped to that exact size rather than using CSS to shrink a huge image.
Flexibility - I can change the size of images and return that exact size to the app without having to re-upload images. For example, if my product page pulled in thumbs at 40px, I could easily make a call to grab the same image at 50px.
Hope this helps.
http://cloudinary.com/
You can do all of this using the meteor package collectionFS. The package is well documented and you have a variety of options that you can uses for storing the uploaded files. CollectionFS also gives the ability for image manipulation on the upload, such as creating a resized thumbnail.
I realized this question is a bit old.
I had the same problem, one of the solution that works for me is using meteor-upload https://github.com/tomitrescak/meteor-tomi-upload-jquery
Definitely don't store stuff in the public directory - it will slow down starting up the app, and hot code refreshes on image upload could easily cause it to crash once there are a decent number of images in there.
Any of the above solutions with storing images elsewhere would work. One other option is using the peerlibrary:aws-sdk package to upload stuff to S3, which is what I use for several apps and have found to be very clean.
Storing the image as a base64 string in MongoDB is also a method. Useful for posting to APIs and save the worry of having to handle other 3rd Parties.
The first bit before the _ is the id of the pin...what are the ZZtfjmGQ used for? I'm assuming the _c is probalby something to do with size.
http://media-cache-lt0.pinterest.com/upload/33284484717557666_HZtfjmFQ_c.jpg
I'm building an image upload service in node.js and was curious what other sites do to store the image.
Final images are served from a CDN, evident by the subdomain in the URL. The first bit, as you pointed out, is the id of the image, the second bit is a UID to get around cache limitations for image versions, and the last bit is image size.
A limitation of CDNs is the inability to process the image after upload. To get around this, my service uploads the files to my Nodejs server where I then serve the image back to the client. I use a jQuery script the user can use to crop the image which sends crop coordinates back to the server and I use ImageMagick to create the various sizes of the the uploaded image. You can obviously eliminate the crop step and just use aspect ratio's to automatically create the needed image sizes. I then upload the final images to the CDN for hosting to end users.
When a user needs to update a photo already in the CDN, the user uploads to nodejs server, images are processed and sized, the UID hash is updated and then uploaded to the CDN. If you want to keep things clean (and cut on CDN cost) you can delete the old "version" at this step as well. However, in my service I give the option to backtrack to an older version if needed.
The rest of the CRUD actions are pretty self explanatory. You can read a list of images available from the CDN using the ID (My service has a user id as well as an image id to allow more robust query operations) and deleting is as simple as identifying the image you want to delete.
I am working on a ecommerce site built on the top of Nop Commerce 2.3. We want to use CDN for loading all static contents including its images, but not sure how to do this with NopCommerce.
Nopcommerce is set to save binary of images in db at the time of inserting product, and then it generates thumb or re-sized / optimized images at the run time as and when required and stored them in the content folder of the same application for retrieving on page during load time.
Now, suppose on some page, lets say, Home Page, we have 70 product images. I want to distribute it across four host name, so each host name will serve 17/18 images.
This is definitely to save some time in image loading.
Now the Question is:
How to do it in best way in NopCommerce?
The challenges are:
Changing in nop commerce code to load images from CDN instead of its application\content folder. This is not an issue and is fine to manage.
To implement this correctly we might need some mechanism that checks for image on CDN if it doesn't exist, then we might need to transfer the image from content folder to appropriate folder at CDN maybe ? (suggest), and if it doesn't exist in content folder, then need to generate suitable image first and then transfer it.
I'm concerned about this 2nd challenge, and wants to understand the best approach to do this. Moreover, how to do this... specifically check if image exists in CDN or not?
Not very much sure, how to do this? And is it okay or do you suggest something else?
If you use the OVH CDN, you simply point your dns to the CDN dns, add the static file's extensions to the CDN configuration, and let it work for you. All other extensions will pass through. No code to change.
I'm using the high performance image serving feature in App Engine to serve up images from the blobstore. However, I'd like users to be able to modify those images (e.g. rotate, crop etc.) and then write those change back to the blobstore, overwriting the original blob. I know I can write to new blobs in the blobstore, as documented here: http://code.google.com/appengine/docs/python/blobstore/overview.html#Writing_Files_to_the_Blobstore
but I don't see a way to overwrite existing blobs. Is this possible in App Engine?
My use case is as follows:
User uploads image, and app engine generates a link via
get_serving_url
The user may then use that link outside of my app, e.g. link to it
on their blog to display the image
If that image is changed later on in my app (rotation, etc.) , I'd
like their image link to reflect those changes
Files stored in blobstore are immutable, once they have been written than can not be changed (only served or deleted).
I think you should try to build your own controller for generate file serving url
- In Datastore each blobFile record have own ID (you manage it) and version ID
- for first upload , set new ID and version
- When user change your image, save new blobstore, keep ID and set new version field
In serving controller generate link by iD, when user call it, get the newest version for serving
It's just my opinion, hope it helpful !
I need a way for cache images and html files in PhoneGap from my site. I'm planning that users will see site without internet connection like it will be with it. But I see information only about sql data storing, but how can I store images (and use later).
To cache images check out this library -of which I'm the creator-:
imgcache.js
. It's designed for the very purpose of caching images using the local filesystem. If you check out the examples you will see that it can also detect when an image fails to be loaded (because you're offline or you have a very bad connection) and then replaces it automatically with the cached image. The user of the webapp doesn't even notice it's offline.
As for html pages.. if they're html static files, they could be stored locally in the web app (file:// in phonegap).
If they're dynamically generated pages, check the localStorage API if you have a small amount of data, otherwise the filesystem API.
For my web app I retrieve only json data from my server (and process/render it using Backbone+Underscore). The json payload is stored into the localStorage. If the application gets offline, it will fetch json data from the localStorage instead of the server (home-baked fork of Backbone.dualStorage)
You then get the full offline experience: pages+images.
Caching like you might need for simple offline operation is not exactly that easy.
Your first option is the cache manifest. It has some limitations (like the size of the cache) but might work for you since it was designed to do what you want.
Another options is that you can store content on the disk of the device using the file system APIs. This has some drawbacks like security and the fact that you have to load the file from a path / url that is different than you might normally load it from on the web. Check out the hydra plugin for an example of this.
One final option might be to store stuff in localStorage (which has the benefit of being private on all platforms) and then pull it out of there when needed ... that means base64'ing all your images tho so that is a pretty big departure from just standard caching.
Caching is very much possible on Android OS. but on Apple as stated above there are limitations with the size of the images and cache size etc.
If you are willing to integrate and allow the caching on iOS you can use "cache manifest" to do so. but keep the draw backs and limitations in mind.
Also
if you want to save the file to Documents folder under my App, Apple will reject your App. The reason is the system backup all data under Documents folder to iCould after iOS6, so Apple does not allow big data like images or JSON file which could sync from your server again to keep in this folder.
So there is another work around which is good So one can use LocalFileSystem.TEMPORARY instead. It does not save the data to Library/Cache, but it save data to temp folder of App, which does not been auto backup to iCloud and not auto deleted either.
Regards
Rajeev