jerrygarciuh has asked for the wisdom of the Perl Monks concerning the following question:

Where I Am

I am adding a preview function to my content management script in which users add text and/or images to their page. I want it to be similar to the one used here.

My Problem

I don't want to clutter the server with file_uploads which end up not being used.

My Question

I would like to know if I can use image links to local files selected by the user like so:
file:///C:\WINDOWS\Desktop\randompix\catnthing.jpg
and then if the user OKs the preview we can do the upload. I have tested such links but I have that creeping feeling that there is some problem with this idea, perhaps browsers not reading the file_upload path the same way? Is my thinking flawed?
TIA
jg
_____________________________________________________
If it gets a little bit out of hand sometimes, don't let it fool you into thinkin' you don't care.TvZ

Replies are listed 'Best First'.
Re: Previewing With Local Image Links
by moodster (Hermit) on Feb 04, 2002 at 08:46 UTC
    Ok, let's see if I understand the concept: the idea is that while previewing, the image is kept locally on the client computer and it's only after actually submitting it using CGI->upload() that it gets uploaded to the server?

    I think it might be possible to get this to work using some heavy JavaScript wizardry to snatch the file name from the upload control and modifying the the HTTP request that gets sent to the server so that the file doesn't get uploaded, but the filename does. It's been several years since I did JS stuff however, so don't take my word for it.

    If on the other hand your relying solely on CGI.pm and no client-side scripting, I'd say that it wouldn't work. The file path/name using CGI->upload() is not the path to the file on the client, so you wouldn't be able to use that. You could do it by letting your users hand-type the path into a text box and using that input to build the preview page, but that's not really user-friendly.

    Cheers,
    -- moodster

      The file path/name using CGI->upload() is not the path to the file on the client
      Isn't it? I think that's exactly what it is. There's a post on the front page right now saying "why am I getting the filepath on the client when using CGI.pm to upload?"

      --
      Weaselling out of things is important. It's what separates us from the animals ... except the weasel.

        Mea Culpa.

        After actually reading the CGI.pm perldoc I discovered that I was wrong. But only partially wrong. The documentation also mentions that not all browsers send the whole path; some send only the file name. So you can't rely on the path that gets submitted to preview images anyway (well, not in a browser-independent way, that is).

        Cheers,
        -- moodster

Re: Previewing With Local Image Links
by Cody Pendant (Prior) on Feb 04, 2002 at 05:38 UTC
    URLs beginning with "file:///" are prefectly good URLs.

    What's stopping you creating a temporary version with that as the URL, then saving the final version with a proper URL?

    As far as I'm concerned, you've answered your own question!

    --
    Weaselling out of things is important. It's what separates us from the animals ... except the weasel.

Re: Previewing With Local Image Links
by screamingeagle (Curate) on Feb 04, 2002 at 05:04 UTC
    as far as i know, u cant avoid uploading the image to your server in order to display the image contained in pages which r hosted by your servers... one small suggestion i'll make is that u save all the images in a temporary directory (/tmp, for example) and only when the user confirms his/her selection, move it to the production folder intended for images...
Re: Previewing With Local Image Links
by trs80 (Priest) on Feb 04, 2002 at 20:19 UTC
    I tested to see if something like this would work with just CGI and a staging page, but straight from the CGI docs is this:
        2.  The optional second parameter is the starting value for the field
            contents to be used as the default file name (-default).
    
            For security reasons, browsers don't pay any attention to this
            field, and so the starting value will always be blank. Worse, the
            field loses its "sticky" behavior and forgets its previous contents.
            The starting value field is called for in the HTML specification,
            however, and possibly some browser will eventually provide support
            for it.
    
    My idea was that a user could enter the full path to the file, which would have to be done by hand to avoid using the 'browse' button. Then forward that filename and path to the next page. This works fine, but the file in question can't be auto added to your final real upload because of the browser issue mentioned in the above documentation clip.