On Wed, Aug 5, 2009 at 3:58 PM, Jeremy Thomerson<[email protected]> wrote: > Seeing this thread and similar requests come up before, I have > wondered how difficult it would be to natively support this in Wicket > - via some AjaxForm, etc. Change the ajax submitting behaviors to > submit to an invisible iframe if it finds any file input fields, and > change the processing so that when it returns the JS in the iframe, it > is handled in the real frame. > > Has this been discussed before? Is it in JIRA? Is it something we > should add to the 1.5 wishlist? > > Come on, Igor - shoot me down - I haven't throught this through much - > so I know I'm missing something obvious - and it's probably on the tip > of your tongue - right behind "wtf - why didn't you think of (insert > something that I forgot to consider)" :)
you have managed to overcomplicate it; you dont need an ajax form, nor any changes to the ajax behaviors. this is more a problem of logistics, historically these things have been a huge timesink. modal window, something that should be relatively simple, has sucked in enough time to write wicket twice over. so did autocompletetextfield. i think we are all a bit hesitant about introducing more magical javascript. fine. maybe the time has come to bite the bullet on this one. see WICKET-2420. currently it works in firefox, save a minor problem with the browser spinner which never seems to stop. it fails in all the other browsers in slightly different ways. even at 30 lines javascript can cause a headache. let the fun begin, i hope you like tweaking javascript :) -igor > > Happy Wednesday. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > > On Wed, Aug 5, 2009 at 5:51 PM, Igor Vaynberg<[email protected]> wrote: >> well, its complex because you have to hack this in, browser's built in >> ajax support doesnt handle multipart requests yet. >> >> sounds like you are overcomplicating it by prerendering the iframe in >> the output. i think it would be easier to create the iframe on the fly >> via javascript, and give it style='display:none' so you wouldnt need >> to do any sizing. >> >> if upload fails the response in the iframe can write out some >> javascript to notify the main script that is managing the upload - >> which can then somehow show an error - maybe by doing an ajax request >> to wicket and rerendering the feedbackpanel. >> >> if upload is successful do the same thing, have iframe write out a bit >> of js that notifies the main script that the upload is done - which >> can then issue an ajax callback to wicket. >> >> makes sense? btw, there have to be libs that do all this for you on >> the js side of things. >> >> -igor >> >> >> On Wed, Aug 5, 2009 at 3:42 PM, Bas Gooren<[email protected]> wrote: >>> Hi all, >>> >>> Since I've seen many great answers on this list it's time to ask one of my >>> questions ;-) >>> >>> The thing that strikes me as odd is how hard it is right now to handle file >>> uploads and respond as if it were an AJAX request. >>> I've built (based on various sources) a solution which uses a Panel which >>> contains an IFRAME. After the upload, some AJAX javascript is rendered >>> which calls an abstract function on the Panel so the implementor can >>> replace or re-render components. This works great, although it took some >>> extra effort since the frame and panel cannot easily share state (different >>> pages/pagemaps/...?). The examples on the web store the uploaded file, and >>> then pass it's filename through the AJAX request for access. I changed it >>> to store uploads in temporary storage, identified by UUIDs. >>> >>> Now I have to say I really don't like this solution, since the IFRAME has >>> to be sized to fit, or I have to use some not-so-nice javascript to >>> automatically resize the IFRAME when an upload error occurs. >>> >>> Since I have had great fun with swfupload + PHP before, I decided to try >>> and make an easier solution. I wondered if it would be possible to: >>> >>> 1) extend AbstractBehavior (works) >>> 2) render the swf which will upload the file (works) >>> 3) give the swf the URL of the behavior (works) >>> 4) handle the upload(s) in onRequest() (does not work) >>> 5) and then, just like AbstractDefaultAjaxBehavior.onRequest(), build an >>> AjaxRequestTarget and handle the request (like it came in over xmlhttp) >>> (works) >>> 6) use javascript (Wicket.Ajax.Call.loadedCallback) to parse the (fake) >>> AJAX response >>> >>> Sounds possible, right? It just seems overkill to run a POST request _and_ >>> an AJAX request for every upload. It seems more complex than it should be. >>> Actually, with the IFRAME it's three requests: IFRAME GET, IFRAME POST, >>> AJAX GET >>> >>> What is not working right now is: >>> - POST request not directed to the Behavior (I'm assuming there is >>> special-case handling for POST somewhere?) >>> >>> Anyway, I'd like to known if any of the devs think the above is possible. >>> If not, I'll stick to the solution I'm building right now (swfupload to a >>> mounted URIRequestTargetUrlCodingStrategy + UUID in the URL, AJAX request >>> with this UUID after successful upload). >>> >>> Ofcourse it's also possible something like this is possible but needs a >>> completely different angle. >>> >>> Kind regards, >>> >>> Bas >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
