APF-590: File Upload Progress Indicator

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

APF-590: File Upload Progress Indicator

David Whitehurst-2
Let me first say, this is quite the task, lol.

I think there are two chunks to this "backlogged" problem. I am taking the challenge. The two pieces are:

1. Java method to 1) know the file size being uploaded and 2) get the current filesize on disk or know how many 1's and 0's we have sent from the user's machine to the server so far.

2. Javascript strategy to produce a modal dialog that remains (with status) until the file transfer is complete.

I started on my own project with Tapestry and I'm banging my head because I jumped in with both feet and thought I could just knock this out. I was wrong.

The <t:upload component uses Tapestry code ... that uses Apache's common-file stuff and I'm not sure that we want to use each Web stack's method or strategy. I want us to have a solution that Java web developers snag when they go to Google. The whole thing (various code mechanics) is not documented very well and I go into a total state of confusion when it comes to the JavaScript end of things.

1. Does everyone agree that we should have a solution that's our's?

2. Either give me a choice of JavaScript(libs, api, etc.) solution for all or tell me what's the AppFuse strategy for client-side development either across web-stacks or different for each?

My vote is to solve the actual bytes transferred thing with Java and share it with the world because I find a lot of BS progress indicators that just play the animation and it's meaningless. I say show the animation if the file is big and we do need to entertain the user. For the second question, we have the same problem at work and they know I don't like Javascript.  It's not the Javascript itself, it's that every year or so, all the new developer's start the new-API craze and they sell the bosses on introducing the new stuff because the bosses don't care and should.  They should care because they don't see the jQuery-no-conflict-with-tap5.js file in the repo.  Oh, and the dance at the board table trying to explain why Prototype stopped working with jQuery.  And, we are using this UI pizzazz to show executives and the data behind it all isn't even real. I just withdraw like a clam back in the sand.

What do we think? Let's come up with some concrete design. The midnight coding exercise didn't work.

P.S. Matt, you should be very proud of your accomplishments. I have had this hangup about client-side development and browser support for a while now but my resolution for 2015 is to establish a process for myself to solve it and to be comfortable with my solutions. The Web UI Architect has a market for sure. I need to be part of that because they're going to use JavaScript whether I like it or not. My attempt at the progress bar so far was using jQuery and I am loving that.

Cheers,

David
--
David L. Whitehurst
2932 Tram Road, Fuquay Varina NC 27526
919-605-6529 (mobile)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: APF-590: File Upload Progress Indicator

mraible
Administrator
I used to think it was best to have a single solution that spanned all the different frameworks. For example, SiteMesh. However, over the years it's become more and more apparent that it might be better to use what a framework provides (if they provide it). This allows the frameworks to be developed independently w/o having to know how each one works. That being said, in light of the new "if it makes it easier to maintain, let's do it" mantra, a single solution might be best. 

I've used the following jQuery File Upload component before and it worked quite well.


Another thing to keep in mind is this ticket is from 2007 and we should do a better job of cleaning up JIRA and only concentrating on things we'd like to see. It does seem like a nice addition though. Maybe it could be combined with http://issues.appfuse.org/browse/APF-669.

On Sat, Dec 20, 2014 at 10:57 AM, David L. Whitehurst <[hidden email]> wrote:
Let me first say, this is quite the task, lol.

I think there are two chunks to this "backlogged" problem. I am taking the challenge. The two pieces are:

1. Java method to 1) know the file size being uploaded and 2) get the current filesize on disk or know how many 1's and 0's we have sent from the user's machine to the server so far.

2. Javascript strategy to produce a modal dialog that remains (with status) until the file transfer is complete.

I started on my own project with Tapestry and I'm banging my head because I jumped in with both feet and thought I could just knock this out. I was wrong.

The <t:upload component uses Tapestry code ... that uses Apache's common-file stuff and I'm not sure that we want to use each Web stack's method or strategy. I want us to have a solution that Java web developers snag when they go to Google. The whole thing (various code mechanics) is not documented very well and I go into a total state of confusion when it comes to the JavaScript end of things.

1. Does everyone agree that we should have a solution that's our's?

2. Either give me a choice of JavaScript(libs, api, etc.) solution for all or tell me what's the AppFuse strategy for client-side development either across web-stacks or different for each?

My vote is to solve the actual bytes transferred thing with Java and share it with the world because I find a lot of BS progress indicators that just play the animation and it's meaningless. I say show the animation if the file is big and we do need to entertain the user. For the second question, we have the same problem at work and they know I don't like Javascript.  It's not the Javascript itself, it's that every year or so, all the new developer's start the new-API craze and they sell the bosses on introducing the new stuff because the bosses don't care and should.  They should care because they don't see the jQuery-no-conflict-with-tap5.js file in the repo.  Oh, and the dance at the board table trying to explain why Prototype stopped working with jQuery.  And, we are using this UI pizzazz to show executives and the data behind it all isn't even real. I just withdraw like a clam back in the sand.

What do we think? Let's come up with some concrete design. The midnight coding exercise didn't work.

P.S. Matt, you should be very proud of your accomplishments. I have had this hangup about client-side development and browser support for a while now but my resolution for 2015 is to establish a process for myself to solve it and to be comfortable with my solutions. The Web UI Architect has a market for sure. I need to be part of that because they're going to use JavaScript whether I like it or not. My attempt at the progress bar so far was using jQuery and I am loving that.

Cheers,

David
--
David L. Whitehurst
2932 Tram Road, Fuquay Varina NC 27526
<a href="tel:919-605-6529" value="+19196056529" target="_blank">919-605-6529 (mobile)

Loading...