I'm using embedded web browser from Bsalsa to write an email client in Delphi
I have a problem with cid embedded attachments such as:
<IMG src="cid:5D4219C71EAE43B1864AE9CB27C224A8#somehost">
I store the attachments in the database but can't figure out how to provide them to the browser. It seems custom moniker might need to be implemented but the documentation is scarce.
Any help would be appreciated.
I've implemented it using a "pluggable protocol" handler and it's easier thant it looks. Start here: http://msdn.microsoft.com/en-us/library/aa767916(VS.85).aspx and here: http://www.bsalsa.com/protocols.html
I am sorry I can't share the code I wrote but it's written for the company I work for and I have restrictions about it. Basically you need a com object that implements the proper interface to get the data and allow the web browser control read them.
That's IMHO the correct way to do it - altering the mail and storing temporary data may bring issue in the long run.
The simplest solution is to extract your "attachments" as requested into a temporary folder, then change the reference in the source to point to these temporary files, prior to being displayed. In the past I have used diHTMLParser to just this with great success.
If I remember correctly, the message contains these mime attachments along with an optional filename which doesn't always exist, but will have a mime type so you might have to have a translation table to get a default file extension for an attachment. Also, keep track of the files you place in your temp directory and clean up once your message window is closed. If you allow multiple messages opened at once, allow for name collisions and generate unique files.. it is common for signatures to have the same name, but be from different people... can be confusing if your message from John is signed Mary. :)
Related
Whenever we upload a media file to our Umbraco CMS, it generates a unique media id in the filename. So a file like example.jpg will be given a url like:
http://content.example.com/media/947/example.jpg
And if we update the file, it gets a new media id.
This is incredibly annoying, because there's no way to make a permalink to the image! We want to be able to create links to image files that non-technical people upload, but having a random and possibly changing id in the url means that any such link is in danger of breaking without warning.
So, is there any way to upload media files to Umbraco and have them placed in a static location?
First of all, we need to think: for what we want to use it? If it will be used inside the currently developed website and needs to be managable, I don't see any reasons why current url convention or anything else with media may be considered as a blocker / barrier. It just requires to enable editors to select media in document types properties (in proper way e.g. using MediaPicker, MultiNodeTreePicker etc.) and while it's processed and rendered we can easily grab the URL of the file having media id and put this anywhere in the HTML markup. Ba! It's even better in my opinion, cause when we delete or re-upload the file, we don't need to change anything else inside the code or markup or logic, cause ID of the media file is not changing and we're still able to use it.
I don't know if any CMS enables users to be responsible of media files URLs creation... But if this is a case, basically, there is a way (or even more than one) to achieve this:
"Hacky way" - "File" document type and template returning data
You can create new document type with MediaPicker property inside of it. Then create and assign template with C# / Razor logic (depending if you want to e.g. hijack the route with custom controller or just render or return file inside the template) and just return file data in your desired way. If you want to display image - you can render it, if you want to play the audio or video - you can return proper objects / html5 tags or anything else. It may be a long switch statement covering all of the allowed file types and methods of returning them to user. You can also process the file and return it in HttpResponse to force browser to send file and user to download the file to his disk. Tricky one.
"Umbraco advanced dev way" - Custom FileSystemProvider
We can create custom FileSystemProvider and assign it to be used in MediaFileSystem. It can swap whole media workflow of retrieving and adressing the media. To be honest, I wasn't playing with this too much, but there is open-source project of media provider which stores media on Azure Blobs (https://our.umbraco.org/projects/collaboration/umbracofilesystemprovidersazure/) so we can preview how it's done there and adopt to our own scenario.
More info about custom FileSystemProvider: https://our.umbraco.org/documentation/extending/custom-file-systems.
"Not recommended way" - Duplicating files in custom directory during MediaService save event
It's the worst solution from the above in my opinion, as it removes all the great features which Umbraco gives us "out of box" for managing and processing media files (e.g. ImageCropper), but... we're able to hook up into MediaService events (https://our.umbraco.org/documentation/reference/events/mediaservice-events) and do whatever we want with file(s) uploaded to our site. It means that we're also able to duplicate files and place them to our custom directory which needs to be adopted and adjusted to be visible and used "from the outside".
So, as you can see - everything is possible :) But, getting back to the beggining of this long post - we need to think for what we want to use it and if we really need it. I still can't find any use case where I needed cool, awesome, custom media file IDs. If I would need them, I will use any url shorteners e.g. bit.ly, for campaing or anything else what will also give me a great analyze tool providing me data about number of downloads for example.
I'm working on switching an iOS app over from storing data using archiving to accessing XML files on a web service, in order to have one central database for many users. I've found resources explaining how to use NSXMLParser, but very little that explains how to create or edit XML files on the database with information entered into text fields on the app.
The web service is up and running, but the Catch-22 is that I can't verify that my parser works properly without also being able to enter data and having it save to the web service.
The data is pretty basic. For example, I might have a Car object that has a few NSString properties- year, make, model, color, and so on. I need to be able to add and delete Cars, as well as edit the properties. Suggestions?
In terms of reading the data, I recently wrote a simple XML parser for iOS called ConiferXML. You can check it out at GitHub. If this doesn't work out there is also another library on GitHub that is a little more complex but does the same thing.
I'm trying to do something a bit complicated and I'm not entirely sure how to go about it. Could you please give me some pointers on the tech I should use and how I should go about implementing this. Here's what I need to do:
Create an iOS app that allows the user to upload pictures from his camera roll and modify variables with sliders. (so far so good)
These variables and graphics are used to modify some htlm5 code (i.e. the graphics the user supplies are called by the hmtl code and the variables modify some set variables in the script) (Do I just edit the code as a string?)
The code is put together and uploaded to a server where it is accessible at a unique URL. The user can save multiple times and each time it creates a new URL. (Do I need an FTP here?)
Your question is too general, but as far as I can help, Yes you have to create and edit some html source texts, and append every object that user is adding to the page as some html codes, files, css, etc.
and for uploading, if you want the user to upload the site to his/her own ftp server or web hosting service, yes you need FTP connection to create with the server.
But if you want your user to upload the website to a space you're providing for the user, then you need some server part and maybe some APIs. then you may use FTP or even some APIs to create and update files on your server. It highly depends on the service you want to provide.
I've been researching the best way to implement an application for my brother's business, and have been pretty stumped in terms of how to structure my application. The application will be run on iPad 2's deployed in the field, sometimes without readily available network access (due to spotty cell coverage in the area).
Here is the abstract on what it needs to do:
1) Load a template PDF file (its a contract to sign up for what is basically cable service) that has editable fields, such as:
a) Name b) Street address c) Dates
2) be able to collect a drawn signature (very similar to any credit card app, such as Square, etc), which is then overlaid onto the PDF.
3) Save the PDF, containing drawn signature and other edited fields, as a new file. Then, upload it to a backend server, using the name of the individual and date/time as meta data for sorting into specific folders.
Without this third aspect, an employee would have to spend 30 minutes to 2 hours a day categorizing all of the app submissions, so step number 3 is a pretty important aspect to the development, even though most of the work is outside the realm of objective C. Still, i need to send the PDF file off with as much information attached to it as I can...
I'd appreciate any guidance related to the best course of action in developing this. Are there any open source applications that you guys know of that I can reference to? I have searched Apple's Developer member center and Google to no avail.
How could i implement iText properly here? Is that even the best option?? It does digital signatures as opposed to those drawn with UI Kit...
Sounds like you should have a web service with a database for storing the meta information and the path to the generated PDF with the signature and other entries.
Your app would essentially generate the PDF, make a web service call and insert information such as the client's name, date/time, whatever else you want, and then the name or path of the PDF file. The PDF file would subsequently be uploaded to a designated location with a unique file name to prevent overwriting another PDF. You could formulate the name of the file off of the corresponding Key/Id of the record in the database or you could use a GUID as the filename and for good measure concatenate the EPOCH timestamp when the file was generated. Both approaches should guarantee filename uniqueness. Another possible file name scheme Device UUID+epoch timestamp, many options available.
If you have to actually edit the PDFs, it sounds like a pretty hard requirement. Another approach would be to show the user what they need to see (ie what they have to sign) and then generate the PDF with the signature and fields populated. Since you want to upload it anyway you would probably save yourself headaches if you offload this from the iPad and do it using a remote server (as Chris suggested) generating the PDF as you need it. I've been involved in helping out an iPad app development doing property inspections - it used Docmosis to do the document generation in preview and then in submitted forms. Hope that helps even though it's a few months down the track.
I have a number of documents (mainly Word and Excel) that I'd like to make available to users of my Rails app. However, I've never tried something like this before and was wondering what the best way to do this was? Seeing as there will only be a small number of Word documents, and all will be uploaded by me, do I just store them somewhere in my Rails app (i.e. public/docs or similar) or should I set up a separate FTP and link to that? Perhaps there's an even better way of doing this?
If they're to be publically accessable, you definitely just want to stick them in public somewhere. Write a little helper to generate the URL for you based on however you want to refer to them in your app, for cleanliness (and so if you do change the URL later, for example to bucket your files to keep your directory sizes under control, you don't have to change links all over your app, just in one place.
If, on the other hand, your files are only for logged-in users, you'll need to use something like send_file to do the job, or one of the webserver-specific methods like the X-Sendfile header to check the user is authorised to view the file before sending it back to them.
I would do as you suggested and put them in public/docs. If you are planning on making an overview/index page for the files and link directly to them it would be easier if they were stored locally instead of a remote FTP server. However, since you are the one who will be uploading and maintaining these files, I think you should go with the option that's easiest for you.