Uploader requirements

Wed Oct 29 16:02:25 UTC 2008

Thats the core of what Im trying to figure out - is the nesting order
critical :PI will report back what I find

On Tue, Oct 28, 2008 at 6:15 PM, Colin Clark <colin.clark at utoronto.ca>wrote:

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

-- 
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/20081029/109aee21/attachment.htm>