colin.clark at utoronto.ca
Tue Oct 28 22:15:41 UTC 2008
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
On 28-Oct-08, at 1:54 PM, Jacob Farber wrote:
> Ok, so far this structure is what I have gleaned from the markup:
> and I know i am missing
> but I cant locate them - are they added/removed dynamically? I can't
> tell at the moment in demo mode.
> 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 Farber
>>> University of Toronto - ATRC
>>> Tel: (416) 946-3002
>> . . . . . . . . . . . . . . . . . . .
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>> Jacob Farber
>> University of Toronto - ATRC
>> Tel: (416) 946-3002
> . . . . . . . . . . . . . . . . . . .
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work