Uploader requirements

Tue Oct 28 19:41:22 UTC 2008

This is interesting Jacob, thanks for putting it together. Is this  
hierarchy for the out of the box markup or does all markup that uses  
the uploader require this hierarchy?

Michelle

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
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081028/7449bd9f/attachment.htm>