On Wed, Aug 5, 2009 at 4:10 PM, Bas Gooren<[email protected]> wrote: > Igor, > > First off: thanks for the amazingly fast response! > > Yes, it feels like I'm overcomplicating things. But then again: there does > not seem to be an easy way. > An upload + AJAX refresh always needs 2 requests, which means (for me) that > I need to preserve the upload somewhere between those requests. > > Since this stuff is very easy on other platforms it's just too bad it's like > this with Wicket.
this is the price you pay for abstraction. It is easy on other platforms because this is something that is accomplished by working with low-level http artifacts - http requests. something like php or jsp or servlets have no abstraction, there it is much easier to do this then to write a complex UI. in wicket, because of the abstraction, this is reversed - easy to write UI, more difficult to wire http requests together like this. its a good thing that 99% of the time is spent writing UIs :) > I mean, I really love Wicket, and most of my new projects > are built on Wicket. > But things like this one (http://www.uploadify.com/) I'm trying to wrap in a > component/behavior right now is difficult to say the least. didnt really look into it that much, when i went to the demo tab it crashed my firefox :| > One of the working components I built using IFRAMEs is actually not that > complex (400 LOC), > and the problem is not so much in the rendering. > It could also be the complexity is in the wrong place... Right now this is > the flow: > - handle upload, store temp file, pass uuid to client > - client runs ajax request with the uuid > - ajax handler in wicket processes the temp file, and re-renders components > > I could choose to process the files @ upload time, and the ajax request only > re-renders elements. Though that does mean components which embed the upload > component need to implement two methods (processUpload, processAjax) instead > of one (processAjax(upload,ajax)). > > How would you go about building a component or behavior for Uploadify? > Let's forget about the IFRAME solution for a second: flash-based uploading > replaces the IFRAME. > > Regards, > > Bas > > ----- Original Message ----- From: "Igor Vaynberg" <[email protected]> > To: <[email protected]> > Sent: Thursday, August 06, 2009 12:51 AM > Subject: Re: Handle file uploads in Behavior and respond using > AjaxRequestTarget > > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
