Uploader requirements

Tue Oct 28 20:12:26 UTC 2008

So far, this is the only heirarchy I've seen so I can only assume its
required (Colin & Eli, please correct me if im wrong). I've tried skipping
some things and it breaks.
On Tue, Oct 28, 2008 at 3:41 PM, Michelle D'Souza <
michelle.dsouza at utoronto.ca> wrote:

> 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
>
>
>
>

-- 
Jacob Farber
University of Toronto - ATRC
Tel: (416) 946-3002
www.fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081028/0d87a3d6/attachment.htm>