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<b...@iswd.nl> 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
