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.
Related
I am working on an xpages app, where the client wants to restrict the size of images that are pasted into the document. I have restricted docs with the upload component, but not with a pasted image.
Has anyone done anything like this?
Thanks
walt
Yes it is possible, I haven't done this but there are a few ways you could go about it.
Excuse me if you already know this, but it is worth pointing out for anyone who comes across this question in the future, RichText as we knew it from Notes/Domino is not used XPages, it is all MIME. When I started Xpages I knew nothing about MIME so after understanding it all I have written a little summary on my blog to help anyone get used to the idea. If you are going to do anything with the InputRichText control and File Uploads etc. it is worth getting familiar with MIMEEntity's.
http://camerongregor.com/2016/04/21/webmail-ui-you-must-learn-about-mime/
There are 2 ways that images can make it into the 'rich text field', either uploaded using the 'Image' button on the editor toolbar, or alternatively in some web browsers, the image can be pasted from the clipboard. The 2 different methods will include the image in 2 different ways
Uploaded
If the image is uploaded, then the image becomes a multipart/related mime entity of some sort of image/jpeg, image/png etc., related to the text/html. Between the time that the image is uploaded, and the time that the Document is saved, the image file will be located on the server's disk, in the xpages persistence folder associated with the Document e.g.
xsppers_directory/application-id/session-id/document-id/someimage.png
Pasted
When pasted the image is not uploaded as a file to the server's persistence folder, but is instead included within the text/html as a data URI image (as Stephan mentioned in the comment above).
So, if you want a true solution you will need to address both avenues.
Handling Pasted images
I have shared a plugin on my blog which blocks pasted images, so this could be used to eliminate the 'paste' avenue altogether, and force users down the upload avenue.
http://camerongregor.com/2016/11/14/preventing-pasting-of-images-in-ckeditor/
Alternatively, if you are happy with having smaller pasted images, you could just 'restrict' it by modifying the plugin so that it checks the 'length' of the data URI (as Stephan suggested above) and allows the paste if the length is below your predetermined limit.
If even more alternatively, you could find some sort of client side javascript library that will resize images and do it there in the client before the paste.
Or another server-side option is you could process the contents of the 'text/html' MIMEEntity when saving, and find any img tag's that used Data URI's and strip it out, resize the image using some server side library such as ImageMagick and replace it.
Handling Uploaded Images
For uploaded images, an intense solution would be to extend the InputRichText control (similar to how the have demonstrated in the Mastering Xpages 2nd edition) and override the processAjaxRequest event so that it resizes the image during the process of uploading of the image and putting it in the persistence folder. You could resize it there and then using something like ImageMagick.
Or a less intense version would be to process the 'pending' attachments during a before save event. If you get the DominoRichTextItem from the DominoDocument, you should be able to iterate through the Attachments, checking their attachment state, there will be a state which means 'pending/about to upload' and for these ones you can process them while they are in the persistence folder, before they are finally attached to the document.
Finally if you don't want the xpages runtime / persistence directory to be involved, you could do it all after save, just using the backend NotesDocument and MimeEntity processing. Extract the Image MimeEntities to disk, process them with ImageMagick or similar, and then re-attach them.
Someone else may have a simpler solution that I haven't thought of but at least this gives you some idea of what may be involved.
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.
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.
Suppose we have a module that displays tables of employees. Each employee has a photo. What is the best way to store this photos and display them?
I mean, is there some kind of content repository in drupal? I don't want to do this manually, maybe there is an API that can store images and then generate links to them and so on.
Thanks.
The Content Construction Kit(CCK) / Fields in core is what you want to explore.
Using CCK you can attach an image, a number field, a file, some text, a reference to content, etc to another piece of content.
In Drupal 7 you can add fields to any entity (Content, User...your custom one(Employee)), in Drupal 6 you might want to explore Content Profile
Further Reading:
http://drupal.org/node/717120
There is a kind of content repository in Drupal: both in the database and as storage (disk).
The API for that is documented in a special File upload section.
If you want inspiration, the core module called upload.module can serve as example. But be aware that Drupal core, for several reasons, is far from the best and cleanest examples to learn from.
What you are looking for is CCK module with file-field and image-field modules for handling the image upload action.
And for the display of those uploaded images you should use Image-cache
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).