We are developing a web application with ExtJs 4 and Microsoft RIA services + MS SQL Server on the back end. Currently some of the records we store in the DB have attached images to them. Images are stored in binary format in the DB.
What would be the best approach to:
Display them within ExtJs framework
Allow users to upload images via same ExtJs front end
I looked through ExtJs docs and looks like we would need to provide images as basically individual files and use simple img tag for that. Is that correct assumption? Are there other approaches to render images from binary data (which we currently serve via JSON endpoints)?
Is there samples handy for image upload logic?
ExtJS will give you a framework for getting the images via forms to your back end, but what you do with the images from there is completely ExtJS independent. Displaying them within ExtJS is completely independent of the back end logic as well. It's just a matter of finding a way to pipe the data up to the browser just as you would if you were writing a normal HTML page.
I'll take the answer one step further and mention: Storing images in the database is generally a bad idea. At least, storing them in a relational database is generally not a great plan. If I couldn't use a database like Riak (or Amazon's S3) for storing the images, I would probably follow Diodeus' comment and put them directly in the filesystem.
Related
I have two separate Java applications A and B running on different physical servers.
On application A (based on Spring Boot framework ) end users view images and image meta data (over 50k images) and has search functionality including faceted search and will use elasticsearch for this. In this application what is the best way to design the content repository ( storage of images and meta data) such that all images can be cached in memory for high performance access?
Application B:
This is liferay 7 based portal.
Authors uploads images and enter meta data about images (or blogs) such as image description Admin approves/publishes the images. These published images are immediately seen in application A. How Liferay can store images to make it possible? Note that application A cannot use Liferay.
For the second part of your question:
Liferay has an API, that you can use to interface with the rest of the world - e.g. even event based: When an image is approved, do something.
Also, images stored in Liferay have a URL - no need to store them somewhere else, you just need to refer to their URL to access them. I'm not sure if that counts as "Application A uses Liferay", you can judge that.
The first part of your question, "what is the best way to design the content repository?": IMHO that part of the question is far out of scope for stackoverflow.com as there tends to be no "correct" answer, but just personal opinions. There's by far not enough information to come up with a proper answer on this topic.
I wants to populate image thumbnails (image grid) on my web page using JSP. Please suggest the best way. Also please suggest what should I store in the DB, image in binary format or path of the image in text format ?
The correct answer would be It depends on your project requirements
I would like to write my experience, if the images had to be prevented from un-authorized access then database would be a good option, but ASAIK I haven't developed any such application in past 3 years. I would just prefer putting up the images in a folder and then have their name in DB for reference purposes.
I just thing database has more important information to store & retrieve and I don't want to choke the database connections retrieving images.
I'm developing a small data-crunching / visualization app in Sinatra, and am split between two options.
The functionality is that you:
Upload a file to the app.
See a nice visualization of its contents.
Maybe start over with a new file.
So my choices are:
Letting both views (upload and results) be managed by the same template, thus creating a single-page app.
Splitting uploads and the visualization between two pages. You upload a file to '/', then are redirected to that file's URL which displays the results.
Which one is better? The advantage of the first is that I can manage it all within the same page, by passing some local vars between the two views.
On the other hand, the second seems like the more RESTful option - because each uploaded file gets its own URL and can be treated as a resource (more fine-grained control).
So, if you want to provide a RESTful API as well along with the web application, it is good idea to have tow different routes.
If you are planning to have just a web UI, it depends on how much control you want to give to the end-user.
Nothing is wrong with either of the approach. It depends on how much ease you can provide.
I'm coming from a php/mysql background. I'm most familiar with the Kohana PHP framework and I'm trying to learn Docpad. I have a loose understand at this point and I've built out my first website and blog. Static content makes a lot of sense to me on Docpad.
I'm working on my photography site where I want to be able to upload new images to a portfolio. The backend needs to handle an uploaded high-resolution image and create several different copies at different resolutions of the image. My biggest question is how do I keep track of the image meta data that I want to display? Do I generate a physical file for each image that has all the particulars I want to track and use those files as my searchable database, much like how blog posts are setup?
Or should I go the route of using something like MongoDB to store image data there where it can be queried and plugged into a layout?
Regarding handling POST or GET data, should I be reading up on the express.js docs? I'm not really sure where to turn for that.
Wordpress uses TimThumb to re-size it's images: How does WordPress.com resize images dynamically?
Then there is this re-sizing library for node: node package for file attachments and image resizing
If you wanted to created like 3 different image sizes and use the backbone collection in DocPad, then you'd add your different re-sized images to those three different collections/folders. For access the images you might just be able to do it via it's file name. So when you copy, re-size and rename the image, in the rename step, concat the image size at the end, like: coolPhoto-med.jpg and then you could just do hard links to get to the image like /spring-collection/med/coolPhoto-med.jpg or you could use query engine to access them.
The file model has a meta attribute: https://github.com/bevry/docpad/blob/master/src/lib/models/file.coffee#L17
I've yet to learn how to use it yet though.
I know we chatted yesterday on #docpad IRC but I just wanted to answer you here too. If you do code something that re-sizes images for DocPad, please do consider putting it up on Github to share with the community.
I've got an app on Google App Engine that will accept image uploads from users. The problem that I envision is that users will upload these images directly from their cameras, and file sizes are often greater than 1MB, which is the limit for the image API (which would be used to resize the images).
What's the best way to accept the upload of say a 1.5MB image file, and resize it to under 1MB?
While this is not clear in the App Engine documentation, this is possible by using a combination of the Blobstore and the Image Manipulation Service.
You must:
Upload the Image into the Blobstore
Retrieve the Image from the Blobstore
Perform the Image Manipulation with an Image resulting in less than 1mb in size
I've written up a post about this -> http://socialappdev.com/uploading-and-re-sizing-large-images-on-app-engine-11-2010.
Here are two (similar) ways to solve this:
If you want to keep everything controlled yourself, you can put a resize script on a server of yours, which takes the URL to the raw uploaded image (which can be up to 10MB due to HTTP response size limit, but you would have to store it as 1MB chunks in the datastore), downloads it from your application, resizes it, and then POSTs it back to your application. All this interaction would need some kind of authorization of course, so that it can't be abused. Alternatively, POST the image directly to your external server, but then you have to either send the other form data back to your application, or use a separate form for the image upload.
Use an external imaging service. I would recommend Picnik. See their API documentation. As you can see, it lets you make a form that posts the image directly to their servers, then the user can edit the image (and resize), then the image is posted back to your server. With this solution you have to upload the image in a separate form, since Picnik receives all your POST data.
I recommend point 2, because it doesn't require you to go around Google App Engine limitations and since your users are uploading images straight from the camera, they will probably want to do something with them anyways (such as crop.)
That's a conundrum. The "obvious" answer, using google.appengine.api.images.resize, won't work because it's too big. :) So you will have to use third-party software, either on the server (which will be tricky because of App Engine's limitations) or the cilent (e.g. a Java uploader).