on 6/19/03 2:10 AM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>Hey, wait a second. The ad-hoc namespace is added as a wrapper by the >>request processing pipeline, it is *NOT* sent by the client code. > > > I see. I'm still thinking that it's best to reuse an existing namespace > (if there's a suitable one available) rather than make up an ad-hoc one > every time. I'll try to see what can be done. > > >>So, if you upload files from a browser, you have to use multipart-form >>encoding. period. > > > I guess we'll have to live with this. Transparent upload of images is > worth a few design compromises. > > By the way, I'm not able to confirm it now, but it looks like you can't > save images that are drag&dropped from another browser window (i.e. > loaded via HTTP), even though they are displayed in the editor box.
Yes, I was thinking about this last night: linotype uses a trick to achieve transparent image uploading: basically, everytime an image is added a <input type="file"> element is added to the dom and hidden with CSS parameters (yeah, sounds hacky, but it's not that bad after all). If you drag/drop an image, Midas adds it to the dom and visualizes it, but there is no <input type="file"> added to the DOM. Note that is would be pretty easy to add a hook on onmouseup and create that <input type="file"> element, but there is a HUGE problem: YOU CANNOT SET THE VALUE OF AN INPUT TYPE=FILE ELEMENT VIA JAVASCRIPT! This is *the* security issue in browsers (otherwise, I could transparently hack into your computer and steal any document from your harddisk without you noticing it). So, drag/drop transparent uploading of images will never work. > was thinking that this might be security-related (cross-site scripting > and all that), but then why is it able to display the image? Visualizing an image and uploading it are two entirely different things. It's linotype that merges them together. -- Stefano.
