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. 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.
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" <igor.vaynb...@gmail.com>
To: <users@wicket.apache.org>
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<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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
