Uploader requirements

[Colin Clark]

Hey Jacob,

This is awesome. Keep in mind that this structure is the default, but  
it's not necessarily required. You can customize the selectors for  
both the top-level Uploader and its FileQueueView subcomponents. So  
you could, for example, use a different or flatter nesting by changing  
the selectors around.

Try it and let me know if it works properly. If not, it's probably a  
bug.

Colin

On 28-Oct-08, at 1:54 PM, Jacob Farber wrote:

> Ok, so far this structure is what I have gleaned from the markup:
>
> <container>
> <fluid-uploader-queue-wrapper>
> 	<fluid-scroller>
> 		<fluid-uploader-queue>
> 			<fluid-queue-row-tmplt>
> 				<fluid-fileName></fluid-fileName>
> 				<fluid-fileSize></fluid-fileSize>
> 				<fluid-fileRemove>
> 					<fluid-removeFile></fluid-removeFile>
> 				</fluid-fileRemove>
> 			</fluid-queue-row-tmplt>			
> 		</fluid-uploader-queue>
> 		<fluid-file-progress>
> 			<fluid-file-progress-text></fluid-file-progress-text>
> 		</fluid-file-progress>
> 	</fluid-scroller>
> 	
> 	<fluid-uploader-row-placeholder></fluid-uploader-row-placeholder>
> 	
> 	<fluid-scroller-table-foot>
> 		<fluid-uploader-totalFiles></fluid-uploader-totalFiles>
> 		<fluid-uploader-totalBytes></fluid-uploader-totalBytes>
> 		<fluid-total-progress></fluid-total-progress>
> 	</fluid-scroller-table-foot>
> </fluid-uploader-queue-wrapper>
>
>
> <fluid-uploader-browse></fluid-uploader-browse>
> <fluid-uploader-pause></fluid-uploader-pause>
> <fluid-uploader-resume></fluid-uploader-resume>
> <fluid-uploader-cancel></fluid-uploader-cancel>
> </container>
>
> and I know i am missing
>
> fluid-uploader-num-uploaded
> fluid-uploader-bytes-uploaded
>
> but I cant locate them - are they added/removed dynamically? I can't  
> tell at the moment in demo mode.
>
> Thanks
> Jacob
>
>
> On Tue, Oct 28, 2008 at 12:54 PM, Eli Cochran  
> <eli at media.berkeley.edu> wrote:
> I'm sorry to say that we don't.
>
> The markup is the closest thing. Markup is king.
>
> - Eli
>
> On Oct 28, 2008, at 9:48 AM, Jacob Farber wrote:
>
>> Do you have an in-depth map of how the selectors need to be nested?
>> I cant scrub mutch from the docs, and I cant depend on the  
>> uploader2.html example b/c it doest explicitly define whats  
>> important and whats there just for show.
>>
>>
>> On Tue, Oct 28, 2008 at 12:21 PM, Eli Cochran  
>> <eli at media.berkeley.edu> wrote:
>> Assuming that someone uses our markup, there really is only one  
>> required selector and that is the container.
>>
>> That said, this is a complex component.
>>
>> Looking at it from another direction, it is three components: an  
>> Uploader, a Progressor, and a Scrolling widget. Plus, we're also  
>> trying to support a couple of different use cases which have  
>> different behaviors: inline and dialog.
>>
>> Our goal in building it is to expose pretty much every element with  
>> a selector so that a developer can use as diverse a markup as  
>> possible. But it does make for a very dense API.
>>
>> The API will feel more simplified in Uploader2 by the way we're  
>> breaking things up. Uploader will feel like a collection of pieces-- 
>> making it much easier to customize just one part of the whole.
>>
>> But I'd love to look at simplifying it further, and as soon as we  
>> have Uploader2 in good shape, it might be worth thinking of ways to  
>> simplifying it with out sacrificing the user experience.
>>
>> - Eli
>>
>> P.S. I see one selector that we're not using anymore:  
>> "osModifierKey". And Pause may or may not be going away. And we  
>> added one: stateDisplay: "div:first". I'll stop now.
>>
>>
>>
>> On Oct 28, 2008, at 7:41 AM, Jacob Farber wrote:
>>
>>> Hi Colin & Eli,
>>> Currently, the existing Uploader API docs list 25 different  
>>> selectors that are required. I'm not sure if this holds true for  
>>> Uploader 2, but if it does is there any way we could isolate what  
>>> is absolutely required (e.g. a browse and  upload button) versus  
>>> whats just nice to have (e.g. txtTotalFiles and txtTotalBytes),  
>>> and if you don't include the niceties you simply don't get them?  
>>> This way, people could build different levels of uploader  
>>> functionality and experiences, as opposed to a single elaborate one.
>>> Just a thought.
>>> Jacob
>>>
>>> -- 
>>> Jacob Farber
>>> University of Toronto - ATRC
>>> Tel: (416) 946-3002
>>> www.fluidproject.org
>>>
>>
>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>>
>>
>>
>>
>>
>> -- 
>> Jacob Farber
>> University of Toronto - ATRC
>> Tel: (416) 946-3002
>> www.fluidproject.org
>>
>
> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
>
>
>
> -- 
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
> www.fluidproject.org
>

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org