jacob.farber at gmail.com
Tue Oct 28 17:54:33 UTC 2008
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
>> 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
University of Toronto - ATRC
Tel: (416) 946-3002
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work