032311 DOJO MEETING DIRECT TRANSCRIPT
The topic for #dojo-meeting is: http://bugs.dojotoolkit.org/wiki/ProjectMeeting/2011-03-23
rahu1: hi all
jared_j: Evening.
rahu1: T - 8 mins, right?
ttrenka: yes
rahu1: thanks, no agenda on wiki yet, but I'm hoping we can get to the 1.7 roadmap doc in first 90 mins.
iTorrey: Nope, first 90min is phiggins filibustering on ticket triage.
rahu1: wait, we have a way till next release, so we can breathe now
bforbes: don't let phiggins catch you saying that
rahu1: bforbes: may be able to get away with a bit, I have only one identity in Trac
bforbes: hah
rahu1: btw, here is a shorter url for Chris' document
rahu1: 1.7 plan from chrism: http://s.apache.org/17plan
jthomas_: evening
rahu1: *mutters something about gdoc urls*
chrism1: hi all
phiggins: argh. autojoin fail
rahu1: jthomas_: evening, much later for you I suppose
phiggins: crap I never looked, chrism1 i thought you'd started an agenda page
rahu1: chrism1: crafted a shorter url for your plan doc
phiggins: but your 1.7 doc + when can we fix trunk are the only issues I have
chrism1: yeah, there's a tinyurl somewhere too
rahu1: http://s.apache.org/17plan
bforbes: IE9?
chrism1: IE9+ff4
kgf: uhop: wow, nice @ #12455. I would've never guessed. I had thought it couldn't be a base issue, so I was
totally off the trail
kgf: (since the fade seemed to end before the problem occurs, and fades elsewhere worked)
chrism1: need someone familiar with AMD builds to look at #12519
1
chrism1: it's blocking optimization for the mobile demo gallery
kgf: that's also what's been killing the builds for the last 2 weeks
phiggins: #12519
dojogurl: 12519
zhangyp
dojo.js
replacement of AMD with dojo.require/dojo.declare in dojo build cause syntax error
rbackhouse "I am trying to build dojo.js layer which includes dojo.json. Here is the layer for
uhop: kgf: I thought it'll be more complex, something like (IE < 9 || isQuirks), yet jared_j was right --- isIE < 9
helped in all cases
kgf: that's what phiggins wants to nag about
rawld: looking
phiggins: GOD DOJOGURL YOU ARE DUMB
kgf: rofl
kgf: again
phiggins: it's really my python skills
phiggins: i need to fix her
kgf: basically, either wrap that module in an immediate function for now, or AMD needs to work
phiggins: so yes
phiggins: kriszyp, rawld trunk is broken
phiggins: my understanding of it is that kriszyp left it broken because the new loader would fix it?
phiggins: perhaps someone can clarify for me
kriszyp: I did it?
phiggins: dojo.json
kriszyp: oh, that broke things?
kriszyp: I'm sorry
kriszyp: I'll fix that
phiggins: yes we discussed this last week iirc
uhop: kgf: we have a bunch of IE > THIS IE < THAT in html.js in the base --- I guess we should revise all of
them
kgf: uhop: I entered a bug about a couple tests related to html.js failing iirc
kriszyp: do I just need to put a module id on it?
phiggins: i don't know
kgf: I think the returns are causing problems?
jared_j: Are we going to discusss 1.6.1/IE9 at all tonight?
phiggins: *makes an agenda*
2
kriszyp: oh, it has a module id...
jared_j: Or are we focusing 1.7?
kgf: darn wildbill aint here?
phiggins: jared_j: my vote is focus on trunk stability / 1.7, and backport critical stuff to 1.6.1
kgf: he'd probably be one to discuss 1.6.1
kgf: all I know is we're clearly under way fixing IE9 things
phiggins: 1.5.x will die off, unless we hit tons of pressume
ttrenka: daylight savings happened in the US but not Japan, kgf
bforbes: seeing as how 1.7 isn't until summer and we have IE9 bugs in 1.6, I'd say we had better roll a 1.6.1
ttrenka: be patient
kgf: ahhh
kgf: lol
kgf: bforbes: I'm pretty sure we fully intend to
jared_j: I updated a bug today that's actually a bug in dojo/_base/html.js and IE ... IE9 does opacity right now,
but we still use the filter branch.
kgf: but there are still open IE9 issues at least
jared_j: Which is why it's at the top of my mind
kgf: jared_j: is that the one uhop just fixed?
bforbes: kgf: k, just getting my 2 cents out there
jared_j: #?
kgf: http://bugs.dojotoolkit.org/ticket/12455#comment:4
kgf: bforbes: np
jared_j: Haha, yep!
kgf: I'm all for an IE9/FF4-fixing 1.6.1 too
chrism1: roll a quick 1.6.1
jared_j: I think we should fix that in 1.6.1 too
jared_j: That's going to snarl people
uhop: guys, whoever sees something strange with IE9 and FF$ --- file bugs like mad
kgf: ah yeah that totally needs to be in 1.6.1
chrism1: have been
kgf: uhop: can you put that in 1.6branch too?
kgf: (it's marked 1.6.1 anyway)
3
chrism1: i've been tagging with ff4 and ie9 keywords
uhop: I don't expect much problems with FF4, yet IE9 proved to be a lot of grief
kgf: yeah, I tag with ie9 in all mine whenever I remember (which is at least almost always)
uhop: kgf: will do
kgf: so far we had the ellipsis thing with ff4, which peller even got into 1.5.1rc
kgf: not aware what else
jared_j: There's no way to fix that in FF4, right?
bforbes: there's a parser bug we should talk about too
bforbes: that affects every browser
jared_j: The nasty perf parser bug?
kgf: there's not really anything to fix, since you can use text-overflow in ff4 ne?
bforbes: http://bugs.dojotoolkit.org/ticket/12450
bforbes: yup
kgf: but yeah dojox.html.ellipsis just has a huge try/catch around it. kinda bugs me but it's single-execution
kgf: uhop: this is the one I was thinking of before btw: http://bugs.dojotoolkit.org/ticket/12342
kgf: seems there's a few others e.g. 12478, 12493, 12507
dmachi: anyone else have any thoughts on the perf ticket? Its clearly a major performance regression, my
question is how hard it will be to revert to query and solve the issue it was solving a different way
kriszyp: what is broken about trunk?
kriszyp: is the build failing?
uhop: kgf: I reassigned them to me from anonymous and sjmiles
dmachi: kriszyp: yes, the build is failing, the checkout is fine.
rawld: kriszyp: dojo/_base/json won't quite work the way it's written...we can talk about offline, no big deal
kriszyp: what is the error?
kriszyp: I am not getting any errors when I build...
chrism1: kriszyp see 12519
dmachi: I haven't seen / looked for the error myself, i thought it was a known issue, i was just giving the state.
kgf: rawld: it's dojo/json not dojo/_base/json isn't it?
kgf: (not that it isn't confusing that there's two and that base depends on non-base
)
uhop: base depends on non-base? where???
phiggins: dojo.json
phiggins: we've gone over this
uhop: 8-0
rawld: hmmm, thought that dojo/_base/json depended on dojo/json which normally wouldn't work because it
4
depends on dojo, but that's not the case...so I guess i don't see the prob either
rawld: after all
rawld: kfg: _base...my favorite topic
kgf: I thought the problem was the returns in dojo/json
kgf: there are returns directly under the top-level function
kgf: presumably that explodes when it gets unwrapped?
kgf: note that I am generally a newbie to how bd works
kgf: or should I say there are returns before the end of the function
uhop: hmm --- why? why not augment base out of dojo.json? why the direct dependency?
rawld: yeah, looking at dojo/json, after the build transform the resulting module "returns JSON" (or the
object)...but that won't work with the 1.6- sync loader
rawld: kgf: you got it
kriszyp: so what do you want me to do rawld?
rawld: (right)
kriszyp: put it in a nested closure for the time being?
kriszyp: set the module value to dojo.json?
kriszyp: I guess that is what I should do for now...
rawld: looking
uhop: conclusion: nobody knows why the brilliant design decision was made
rawld: the easy answer is push the module value in dojo.json, but then you need dojo (which dojo/json) doesn't
have
rawld: so...
kriszyp: and yeah, add dojo/lib/kernel temporarily as well...
kriszyp: this is temp, right? are build's going to be able to handle this in 1.7, right?
kriszyp: s/are/our
rawld: yes, they will handle it in 1.7
rawld: the real issue is 1.6- create things and stuff into dojo; real AMD doesn't do this
rawld: we solve it in 1.6 with a bootstrap that includes everything in _base
rawld: you could move dojo/json to that kernel boot, and that would immediately solve the prob
kgf: uhop: bigger fish to fry first
rawld: kris: this will be simple to fix once I look at how you're using dojo/json...can I just fix it tonight
kriszyp: you fixing it > me fixing it
kgf: that's fine, it's been borked like that for a week plus
rawld: kris: how do you feel about putting dojo/json in base?
kriszyp: "in base" is nebuluos. It is in base as far as being include in the base buidl. It is not in base as far as
being in dojo/_base directory. Putting it in the latter discourages direct module referencing, which is one of the
points of the module
5
kgf: but there is a _base/json as well?
kriszyp: I get discouraged when I type dojo/_base/some-module anyway
rawld: right, I don't care about where it is...
kriszyp: kgf, yeah, that's the back-compat one
kgf: oops, I'm an idiot
rawld: just need dojo/json to depend on dojo/lib/kernel, push result into dojo; dojo/_base/json depends on
dojo/json, gets dojo/json result for dojo.json
rawld: make sense?
kriszyp: dojo/_base/json provides fromJson (an eval) and toJson (with our proprietary __json__ and json
function support). dojo/json is the standards based one with stringify and parse
kriszyp: rawld, that's fine
uhop: so we don't put anything in the _base now?
kriszyp: uhop, you mean new things?
kriszyp: I think it is fine to put things in _base
uhop: any changed things
uhop: so we just put any module we like at hoc?
kriszyp: you mean changes that break compat? yeah, I was obviously trying not to break base compatibilty
uhop: I wanted to break _base/html.js --- should shards go to _base? top modules in dojo? in dojo/html/? or
anything else?
kriszyp: if something can be used with out base, it shouldn't be in _base though, right?
uhop: hmmm
kriszyp: uhop, yes, please break up _base/html.js, we desparately need that!
rawld: if we make dependencies completely specified, base becomes meaningless
kriszyp: rawld, right that possibilty is where I am going
uhop: so basically, if module has no external dependencies --- it is a top module?
rawld: it is exactly where i'm going
kriszyp: but base is always going to be the "dojo" module id in 1.x at least
rawld: uhop: i don't think so
uhop: I know
kriszyp: uhop, hmm, seems like a factor
uhop: I just want to figure out our user story for 1.x
uhop: before it was simple
kriszyp: my thinking was that top level modules are things we want people to be able to directly reference as
deps
6
uhop: now it is more complicated
rawld: our user story is that released dojo.js includes whatever we decide; that's base
rawld: and that has nothing to do with how the modules exist in the file tree
kriszyp: and if a module is not in base, or it can be used without base, those are the situations where people
would want to ref directly
uhop: rawld: you use dojo.xxx(), it is broken, where should I advise you to look for its source code?
chrism1: have to look at the dojo-base map
uhop: before it was --- look in dojo/_base
rawld: we'll, ideally, the docs should point to the code
uhop: ugly, yet it reduces the search
uhop: what docs?
kriszyp: obviously part of the intent of AMD modules is to move away from dojo.xxx() because it is so hard to
trace back where it comes from
uhop: dojo.xxx? dojo.json.xxx? xxx?
uhop: I am not talking about amd modules
kriszyp: define(["dojo/json",function(json){ json.xxx() -> broken
module/breakage orginates from
-> no question where the source
uhop: I am talking about Dojo 1.x
kriszyp: right, I know, I am how we are moving towards better tracing of where things come from
kriszyp: and that is/will be avaialble in 1.x, not just 2.0
uhop: I don't mind have code all over the directory tree, yet to be sane we should have some kind of sane
algorithm for mapping functionality to sources
phiggins: 1:1 is fairly sane
rawld: uhop: it should be a simple thing to generate a ref module with each reference API doc chunk pulled from
the source
kriszyp: how do we do it now? chrism1 mentioned dojo-base map, I didn't know about that
kgf: uhop: funny, I've already been sorta lamenting the breakup of stuff in _Widget because I'm not sure where
to find stuff anymore
but I realize the modularity is supposed to benefit in the long run
uhop: rawld: of course it is that simple! yet somehow we didn't do it in the last 7 years
kriszyp: or are you just pointing out that at least you only need to look in _base for dojo.xxx()?
chrism1: the fictitious dojo-base map i should have said
kgf: I think that's what he's getting at, yes. things are going to become more scattered if you're interested in
finding out How Stuff Works
kgf: not that it shouldn't still be traceable.
7
schwartz: can I sneak in here for a new grid request?
kgf: a fries plugin?
uhop: I am getting at one thing: I don't see what it buys to us as of this moment, but I see a complication for
users
schwartz: my team recently sent out notice of a new new grid demo/code; we need to finalize our plans to
deliver something for 1.7
schwartz: REALLY want to encourage folks to review/provide feedback; we'll have to lock things down soon for
1.7
kgf: uhop: I'll agree with that, but I'm willing to hear arguments on what it buys us.
uhop: kgf: I am all ears to hear *arguments* and get convinced
kriszyp: uhop it buys us define(["dojo/json",function(json){ json.stringify(myObject);, which will work with and
without dojo _base. in 1.7.
rawld: uhop: are you advocating as we refactor stuff in dojo/_base, the pieces remain in dojo/_base?
uhop: rawld: for 1.x --- yes
kriszyp: missed a ] in there...
uhop: kriszyp: what the point of using it without Dojo base? I don't see much value at least in Dojo 1.x world
kriszyp: because it is lighter
kriszyp: dojox.mobile is already doing non-standard-base builds, isn't it?
uhop: lighter?
uhop: let's use jq because it is lighter too?
rawld: uhop: OK, from my pov, that's (keep base in base) fine...at least we get to refactor some of these ugly
modules
rawld: i like kris's direction, but it's not worth a battle in 1.x (to me)
uhop: IMHO universal modules should belong to a repository way outside of Dojo Core, some universal
repository maybe, which you and Tom are building
rawld: hmmm, isn't dojo/_base/html sorta "universal"
uhop: I am not dead set on using _base for everything, I just don't see much upside in Dojo 1.x world, it feels
like the decision was made on the whim
kriszyp: uhop, we could do that, and have a standards based json module outside of dojo, but there has been
some demand for this, hasn't there?
rawld: kris: are you good on dojo/json...can i turn it back over...
kriszyp: rawld: are you going to fix the build?
kriszyp: whatever needs to be done to dojo/json?
rawld: OK, I'll do that
rawld: tonight....
kriszyp: cool, thanks
8
rawld:
uhop: to my best knowledge so far we had 0 (zero) demand for universal modules outside of Dojo --- all
enthusiasts of that are present in this channel
kgf: speaking of that repository...is that really on the 1.7 agenda?
kriszyp: I meant the json pass through to native
chrism1: shall we go to roadmap now?
phiggins: really, it does feel like something that should happen in a branch and be a proposal
kriszyp: we had a ticket for it, and I think multiple people had asked about it
phiggins: you made the comment (kriszyp) initially "it's easy to back out if it breaks"
rawld: uhop: does "universal module" mean a module that can operate alone?
uhop: kriszyp: I am not saying that dojo/json.js is useless, if this is your implication
particular placement, and it is integration technique
I just question its
kriszyp: ok
phiggins: right, if we ship something we're stuck with it
uhop: I rather have no exceptions, than "except dojo.json that lives outside"...
rawld: fwiw...i didn't move anything out of base that was there (although that hurt me)
phiggins: right, _base is wrong
phiggins: but it's a fact
phiggins: a reality, whatever
rawld: agree...and marketing is as important as our genius engineering...probably more so
uhop: phiggins: +1, I don't like _base either --- it was a bad decision in 0.9
kriszyp: phiggins, which is why I am trying to get a lot of this more controversial stuff in front of people right at
the front of the dev cycle, so we have plenty of time to consider if we really want to do it this way.
kgf: point
phiggins: right meanwhile no one noticed, and all the /nightly/ links were broken for a week
phiggins: or two
phiggins: I dunno howlong
uhop: kriszyp: and I appreciate that
phiggins: i think 1
kgf: phiggins: weren't you the one who said we brought it up last week? lol
phiggins: and I guess branching is hard
phiggins: or svn makes it a pita
9
kriszyp: yeah, I hate not using git for this stuff
rawld: agree!!
uhop: apparently "no one" doesn't include me --- I wrote email, made a post, and even caused a ticket for that,
yet nobody reacted
phiggins: kriszyp: so on that though, is there a way we can push the actual package-ness of npm / cpm
whatever
kriszyp: you mean get it more ready?
phiggins: and this be something you can pull in on top of a "stock" 1.x (.6+) dojo
phiggins: i mean, isn't this the ideal candidate for "real packages"
phiggins: cpm dojo-standards
kriszyp: yes, although my expectation with 1.6 is that you would use cpm with a different loader
phiggins: and you get dojo/json.js etc
phiggins: plugd is another good candidate for that ...
kgf: yeah I wouldn't expect you to use cpm with 1.6 since it doesn't support true AMD
phiggins: okay fair enough
kgf: well, I guess unless you had something translate from true AMD to what dojo can work with.
phiggins: don't we have like 7 versions of something that wraps/unwraps?
rawld: kriszyp: here's how I solve a similar issue to dojo/json: https://github.com/altoviso/dojo-v1.7bootstrap/blob/master/dojo/has.js
rawld: kfg: 1.6 doesn't support AMD? that's news to me.
kgf: rawld: well, the builder doesn't support truly anonymous AMD modules right?
rawld: right... but there are other options in the wild (requirejs/bdbuild)
kgf: which is what kris was saying. "you would use cpm with a different loader"
kgf: oh, you mean for the build though
kriszyp: uhop, just to be clear, the complications for the users you are referring to is that there are a larger pool
of possible modules to find dojo.xxx() in, right?
rawld: kgf: right...understand what you are saying (and finally spelled KGF)
kgf: lol
kgf: no worries, I'm giving you far more trouble than you're giving me by transposing a couple characters
uhop: kriszyp: large pool and more places to search for it
kriszyp: larger pool != more places to search for it ?
rawld: uhop: this is really a problem with our docs, there's the code stack should be hyperlinked right in the API
docs
10
uhop: kriszyp: yes, they both orthogonal
kriszyp: I don't understand uhop
uhop: rawld: no, I don't think it is a problem with our docs. imagine we randomly relocated and renamed our
files, and updated docs --- I think it will flood us we questions "where is..."
rahu1: *sees top of the hour, seconds chrism1's call for the 1.7 roadmap discussion*
uhop: kriszyp: imagine that you moved from a house to an 100-unit apartment
rawld: not if there is a hyperlink right to a source code browser...?
uhop: kriszyp: now imagine that people can look for you on 5 different streets
kgf: rawld: I will fully contend that "UTSL" is not a good answer to shove at newbies
uhop: kriszyp: larger pool --- more files, more places to search --- more directories
kgf: certainly I don't disagree that our source is generally pretty darned illustrative though
rawld: kgf: totally agree, isn't uhop worried that those who want to use the source won't be able to find it?
uhop: rawld: bitter truth --- nobody reads docs, nobody uses source code browsers --- the more logical and selfdiscovering thing, the less things to remember, the better
kgf: rawld: yeah I suppose so
kgf: uhop: I wouldn't say no one uses docs
kgf: I'd say some don't try nearly hard enough, I'd also say it's ridiculously difficult to ensure the docs cover
everything
kgf: but TONS of times I can answer people's questions with docs
ttrenka: I would say that if you asked me or anyone else to try to live-link API docs with source, you're asking for
trouble.
kgf: anyway, I agree with rahu1/chrism. we're gettin' sidetracked
ttrenka: I'd love to pull in some source for sure.
rawld: uhop:hmmm, so you're worried about folks who'd rather look at source (and not being able to grep)
ttrenka: unless we can do that for anyone using the doc tools, I'm not interested, and no offense to that
rawld: ttrenka: this is a "whole nother can oworms"...but we should think about it...someday
uhop: ttrenka: grep is not a panacea, grep for "i", for example
uhop: oops
uhop: wrong guy
rawld: got it
ttrenka: yeah, I know
ttrenka: just don't expect it tomorrow
rawld: agree
uhop: my point is simple: we should have as simple and as logical user story as possible, otherwise we are
11
doing a disservice to ourselves and our users
kriszyp: so we do have a consistent pattern that dojo.x.*() functions are found in dojo/x.js, don't we? are there
exceptions to that in _base?
uhop: it actually pains me that dijit and dojox has different directory structure, and dojo differs from both
uhop: kriszyp: yes, and this is a pain point too enshrined in 0.9
kriszyp: knowing that dojo.x.* maps to dojo/x.js (dojo.json -> dojo/json.js) is far more explicity than looking
through all the files in dojo/_base, isn't it?
uhop: kriszyp: yes
kriszyp: I didn't mean to use the word "explicity", but I kind of like that now...
uhop: that's how Closure is structured
chrism1: Roadmap Doc - http://s.apache.org/17plan ... I'd like to take this very good discussion up about 20,000
ft for the remainder of the meeting...
kriszyp: and of course using "dojo/json" (as a dep/ref) is even more explicity
rawld: kriszyp: I solve the prob like this: https://github.com/altoviso/dojo-v1.7-bootstrap/blob/master/dojo/has.js
kriszyp: sorry, chrism1, looking at roadmap sounds great
rawld: i'll stop now too
chrism1: np, the last hr discussion is all relevant to about 2 of the core areas that need focus
uhop: kriszyp: right now our story: "base? dojo.xxx? look in dojo/_base/ --- there are several files, yet the
separation is kinda logical"; Closure-like story: "there is no base. dojo.xxx? see dojo/xxx.js or something like
that", what you proposes is to ... merge these two stories with "use ALGO1 (long story), if it fails use ALGO2
(another long story)" --- to me it is an increase in complexity...
uhop: ...without much benefits
chrism1: we've tried to lay out a high level release roadmap that's more agressive than past in terms of quick
turnaround
chrism1: basically one major release per quarter
chrism1: which is a much shorter dev cycle
rahu1: good stuff
rahu1: release early, release often
rawld: i think this is awesome
chrism1: rawld, kriszyp, ttrenka, itorrey: does the core library section look doable for 1.7, or should we move
some of these goals to 1.8, based on what we know today?
chrism1: eg. package manager
chrism1: is that really a 1.7 goal
chrism1: if packages and plugins spec is going to come in, which modules will be the exemplars, and how far
does it get taken
kriszyp: yes, although a pacakge manager is independent of the dojo release (which is part of the goal of it)
iTorrey: I was meaning to setup a talk with Kris about the Package manager. I'm open to it being 1.7 but feels
more like a 1.8 to me if 1.7 will involve setting things up to work under a PM system
12
rawld: i am on board with what's denoted as my responsibilities (assuming the work i'm doing now is acceptable
to the group)
kriszyp: the only interdependence with dojo is that it would be nice to be able to use dojo's loader with the
packages, and 1.7's loader should fit the bill fine
iTorrey: the package manager UI is not tied to a dojo release true but coordianting it around a release would be
good marketing I think.
ttrenka: chrism1: I will defer to iTorrey on this at the moment.
kriszyp: other than that, it is independent
kriszyp: and is somewhat functional right now, just really ugly and rough
chrism1: has() branching is kind of tied into the previous discussion, right? seems that kriszyps work to refactor
events and base is paving the way
kriszyp: it'll just needs some lovin' which could happen any time we want to work on it
iTorrey: Yeah we should talk about that at some point this week Kris about getting a plan together for making it
less ugly and have an idea of where it lives and when
rawld: i've got has rolled into the new boot
kriszyp: yes, has() is a big part of what i was working with these module reworks
chrism1: so how far do we take has() branching in 1.7? dojo.core only?
bforbes: kriszyp and I made some great headway on the events layer this week
kriszyp: yeah, there is some decisions to be made about has() usage. I kind of coded to put those decisions off
as long as I could
kriszyp: and I also have been working on adding has() to dojo/_base/query.js too
chrism1: bforbes: yeah, and evan/emmanual have extended that work for touch events
kriszyp: query.js and html.js are our biggest modules in _base (so biggest wins), i remember correctly
chrism1: looking nice
rawld: awesome; using has() is somewhat independent from defining has()
chrism1: splitting those two are big +1
kriszyp: and I don't want to have anything to do with html.js, which is why it would be so awesome if uhop or
someone modularized and has()-ified it
rawld: are we going to continue to maintain multiple query impls
rawld: ?
chrism1: u mean sizzle vs. acme?
chrism1: is anyone maintaining sizzle?
kriszyp: heh
rawld: right
chrism1: it can prob just stay there through 1.x
13
kriszyp: so one thing to mention as I was has-ifying query.js, browser's native QSA don't pass all of our unit
tests
uhop: I am not sure if any of them actively maintained
kriszyp: FF passes probably 90%, WebKit about 85%, IE about 60%, I think
rawld: uhop: i guess that's really my point
kriszyp: so I think users have to opt-in to using a native-only branch/build of code
chrism1: dojox.mobile replaces altogether/juses qsa
chrism1: but option to pull full dojo.query in for desktop compat
kriszyp: which also raises the question of if and how we want to have configuration information exposed to
branching/building. Do we want to do if(has("config-use-native-qsa") && has("dom-query-selector")){ ... nativeonly branch ...} ?
rawld: i don't understand why we would support something not compat with qsa
kriszyp: rawld, qsa's are not compatible with each other when you get into the complex queries, fwiw
chrism1: there's layers of compat
kriszyp: rawld, but I agree with your point
rawld: OK, but then to also add our own flavor....just saying...
uhop: QSA on Samsung TV (FF2-based) is completely borked, dojo.query() defers to it => completely unusable
jared_j: We don't support FF2, do we?
rawld: uhop: right, but dojo.query should work like a good qsa impl...that's all i'm saying
bforbes: is there a *good* qsa implementation?
kriszyp: can we make dojo.query act like ff/webkit qsa without breakign back-compat? I was assuming native
compat had to be opt-in
kriszyp: in 1.x
rawld: well...let's pick one rather than adding a dojo qsa (would that be very M$)
rawld: kriszyp: +1
uhop: jared_j: so what? it is a "new" browser (mumbling: based on FF2)
phiggins: even bforbes gave up on html.js
bforbes: uhop: I wonder what other libs would break on it
kriszyp: or go back down the controversial road of dojo/json, we could ahve a dojo/query that follows native qsa
snover: nwmatcher is the most “correct” JS implementation afaik
phiggins: in uber.js
14
bforbes: html.js is hard!
phiggins: #whining
bforbes: ha
bforbes: we do a lot of normalization
chrism1: so kriszyp , rawld, others: we should work on answering the question on how far we can take has()
branching in core between now and end of Apr...via discussion thread
kriszyp: chrism1, that's fine with me
bforbes: I can take a look at html.js in dojo again
phiggins: fwiw, I hadn't thought has() branching to be a reality until 2.0
bforbes: although, I don't want to own it
phiggins: which is why uber.js and has.js even exist
jared_j: Too late! It's yours
phiggins: *didn't want to break dojo too much*
bforbes: agreed, phiggins
phiggins: but wanted to answer these questions
phiggins: and have a playground
chrism1: next layer is Common UI stuff... bill not here
bforbes: fwiw, kriszyp and I have been doing a lot of experimenting with the events stuff in uber
kriszyp: one other thought to throw out about has(), but doing has a local, it can't survive multiple builds and stay
visible to the build process (needs to be a global for that)
chrism1: Bill/Doug are working on splitting dijit and dojox.mobile
phiggins: because kriszyp et al, WE HAVE TO DOCUMENT EVERY CORNER
phiggins: or people TALK IN ALL CAPS ABOUT US
chrism1: but that work will likely be delayed until iteration 5 timeframe due to IE9/FF4 bug fixing
kriszyp: phiggins is that an argument for not exposing has() in dojo? (just using internally)
phiggins: no not regarding exposing has, just regarding "hey if you load dojo/json you get supermagic"
kriszyp: fwiw, my code so far hasn't exposed has() at all
kgf: so if you guys are reworking event.js, html.js, etc to use has... we have to test both the new impl and still fix
the old impl for reported IE9 bugs
kriszyp: not sure what you mean by supermagic... dojo/json obviously would need docs, although they would be
pretty easy to write since we can refer to native JSON docs
kgf: (just sayin)
15
rahu1: but ofcourse, I ask for Common UI to be within first 90 mins. and we hit it at 98 past ...
rahu1: so the MVC / data binding work got a bunch of good feedback, was incorporated and is ready for trunk
chrism1: for databinding/forms work, ed & rahul have integrated all feedback into the ticket, byut need an owner
rahu1: #12314
dojogurl: rahu1: [patch][ccla] MVC support for dijit based on dojo.Stateful [new/] see:
http://bugs.dojotoolkit.org/ticket/12314
kgf: bugger, still don't have wildbill
rahu1: right, I guess now we need someone with 'svn ci' abilities to teach me the ropes of OSS dev practices
chrism1: would like to issue a vote to see what community feels about this work at this time
rahu1: bugger indeed
chrism1: and take vote to mailing list as well
rahu1: FWIW, in speaking with number of UI architects and devs, this happens to be one of the top two things
that cause people to use custom solutions rather than dijit
kgf: rather than?
jared_j: Well, he is in Japan.
kgf: not in addition to?
rahu1: so can we grant me an "owner" already, happy to do most work going forward?
rahu1: kgf: was that for me?
rahu1: jared_j: yup yup
kgf: yes
rahu1: sorry, what are you asking?
kgf: you said people use "custom solutions _rather than_ dijit" because of lack of mvc
kgf: shouldn't they be...implementing something, while still using dijit as the view?
kgf: or, at least, couldn't, if not shouldn't
rahu1: yup, rather than
rahu1: surprisingly few solutions use dijit in the big deployment of Dojo I've encountered
rahu1: just had this conversation yesterday with one of those folks
chrism1: i've seen this in customer shops as well, they build their own mvc layer
kgf: I mean, I certainly won't suggest that the mvc in the app I'm part of the team on where I work is nearly
gospel, but we basically use dijit for all the view parts.
jthomas_: I'm hugely +1 on the MVC stuff
rahu1: two main issues:
heavy and (b) no bindings
kgf: jthomas_: I think the big question is where it goes
16
jthomas_: I've seen a number of projects building their own versions of this thing on dijit
phiggins: that's the question of the decade though
rahu1: dijit where else IMO
phiggins: dojox exists because of that question
phiggins: cpm too
kgf: because dijit is "dojo widgets" and this is kind of underlying that? or at least that seems to be one side of the
fence I've heard
phiggins: yah like dojo.data
chrism1: dijit is also a fw
kgf: not sure whether underlying/sidelining is a better term
chrism1: all the _ base classes
kgf: 'fw'?
phiggins: again, with something like cpm this becomes moot
chrism1: framework
phiggins: framework
kgf: oh
rahu1: dojo widgets need to know how to bind to data
rahu1: like Flex, like Silverlight, like ...
kgf: phiggins: sure, but what about before then
kgf: or are we leaning on cpm/etc. for 1.7
kgf: and then this becomes one of those "exemplary" packages
jthomas_: I think this is a close enough edge case to live in dijit = my two pence. (2c for you lot)
phiggins: i want to encourage as much "external" contribution as I can
kgf: we kinda need bill to vote on this I reckon
kgf: (on whether it lives in dijit at least)
rahu1: jthomas_: I'll take pence these days
chrism1: yeah, can get his vote on list
phiggins: well bill is bdfl o' dijit
kgf: ya
phiggins: so a vote is moot if he blatantly refuses
chrism1: just want to make sure we do this community way
phiggins: +1
17
chrism1: if it comes out -1 so be it
bforbes: if it comes out -1, we can drop it in dojox
phiggins: dojox isn't the end of the world
rahu1: +1 (non-binding, as they would say in Apache land)
rahu1:
kgf: I could absolutely see this being one of the prime examples out of the gate for cpm though
kgf: that could be pretty awesome
phiggins: also WE ARE ENCOURAGING PACKAGES/GITHUB esque usage
phiggins: right
rahu1: well, -1 needs good justification
phiggins: under the dojo/ foundation git account, maintained by (you)
kgf: as much as dijit is a framework, to me it's all still very L&F related. MVC seems potentially out of scope /
superceding
rahu1: where else would one expect to get the binding ability for dijit?
jthomas_: phiggins: what's the procedure for creating a new dojo foundation package on github?
kgf: that's where the package repo/manager would come in, in the future
rahu1: its easier if its just there
chrism1: y, dylan told me this is still an issue the foundations looking into
kgf: for now...I know you'll hate to hear dojox, but I'm not sure what else, if we're not ready for github packages
yet
uhop: what are we voting about?
kgf: where mvc lives
chrism1: mvc in dijit, or dojox/mvc
rahu1: well, I don't see how it makes users' lives easy
rahu1: but I'll let the powers that be make the call
rahu1: can we just make some forward progress?
rahu1:
kgf: I'm sort of on the fence but leaning towards the be-conservative-about-what's-in-dijit side
kgf: definitely a topic for list
rahu1: what about the lets-keep-dijit-relevant side?
bforbes: is there a live version of this patch somewhere?
jthomas_: If we put it into dojox are we also going to leave the previous mvc efforts?
uhop: kgf: theoretically someone can do MVC on normal form elements... just saying...
18
jthomas_: dojox.wires etc
rahu1: doughays has an old snapshot
kgf: rahu1: nothing's irrelevant about dijit to me, but of course I haven't seen these custom implementations you
guys are speaking of
phiggins: *shakes fist at dojox.wires*
bforbes: it'd be nice if there was a not out of date snapshot...
phiggins: _someone_ is using that, _somewhere_
rahu1: kgf: right
phiggins: bforbes: shhh he'll say "lets put it in dijit"
phiggins: then it'd be in the nightly, if that wasn't broken
phiggins: AND ON THAT NOTE
kgf: rofl
kgf: I believe kris/rawld already discussed that
phiggins: i leave for dinner. we clearly have unresolved issues here
bforbes: hah, I just mean somewhere like doug's site
phiggins: I know I was teasing
chrism1: so the issue to vote on is: "Should MVC be a module in /dijit"
phiggins: feel free to continue, I'll read the backlog
kgf: yep
chrism1: should we take the vote to mailing list
phiggins: but I'm running.
phiggins: voting is a last resort
rahu1: phiggins: what do you suggest then?
chrism1: so continue discussion until next week via irc?
rahu1: can we have it earlier next week (if same time)
rahu1: like top of the meeting
jthomas_: phiggins: leroy says "what about github new packages?"
kgf: we need bill's call anyway, and he's not here
phiggins: right
phiggins: so next week sure
kgf: (RE voting being last resort)
phiggins: but we're all in #dojo all week all day mostly
19
rahu1: ah, one more week ... fun fun
chrism1: The remainder of the content in the roadmap doc is being demonstrated at
http://chrism.dojotoolkit.org/dojo-samples/demos/mobile-gallery/demo.html
chrism1: and we believe most can be contained in the timeframe in the roadmap
chrism1: questionable area is the unified map api...how far that will be baked
kgf: so did we basically say package stuff needs further discussion to see if it makes 1.7 or not (but probably
not)?
kgf: sorry to backpedal just want to have the story straight
chrism1: package stuff, how far to take has(), and mvc in dijit need further discssion on list
rahu1: there is already a thread on "owner"
chrism1: need thread: pros/cons of mvc in dijit vs. in dojox/mvc i think
bforbes: also a live instance of the patch
chrism1: that's in the ticket, u want a demo site?
bforbes: yes
rahu1: sure, this will mostly be a rehash of what I've said elsethreads, do you want to kick that new thread into
gear?
chrism1: some is demod in that gallery under databinding link
rahu1: this is very old code: http://doughays.dojotoolkit.org/dojomvc/
bforbes: wait, I thought rahu1 said that the link in the bug is old
bforbes: right
chrism1: oh, it's not in that version of the gallery...need to add it in
rahu1: before last DDD
rahu1: I suggest looking at above for behavior and patch on #12314 for code
rahu1: I should probably whip a new tarball over to Doug
rahu1: that'd be less gymnastics
rahu1: for others i.e.
rahu1: chrism1: that'd be great to have a mobile version in your site
chrism1: i'll get ed's demos added to the mobile gallery site
rahu1: cool
jthomas_: time out for me i'm afraid, nn folks
PM chrism1: same here, thx all
rahu1: later!
bforbes: ok, so on to the parser?
kgf: was about to say. lol
kgf: wasn't sure how much discussion was intended in here about that, was about to ask if it should be brought
up again next week since it's 8pm ET already
20
chrism1: got very quiet
bforbes: perhaps we can discuss it on the list
chrism1: there is the parser regression issue
uhop: what's wrong with parser?
bforbes: it's pretty critical
uhop: slow?
chrism1: y
bforbes: http://bugs.dojotoolkit.org/ticket/12450
uhop: remove recursion, cut down dead branches
uhop: if somebody helps me write a benchmark, I can tweak the code
dmachi: yes, i know we can make the actual walking faster, but i guess i am curious as to what it was actually
fixing and whether we can go back to the old way with some tweaks instead
uhop: dmachi: IIRC bill wanted to collect some attributes during the descent
dmachi: i created some js-perf tests for each version (linked in that ticket)
uhop: oh, cool
bforbes: wouldn't it be faster to find the widget nodes and ascend to find relevant attributes?
bforbes: find them via query, that is
uhop: "I've discussed a with Bill and he identified one lang issue that is ~3x performance improvement" --- what
is that?
uhop: bforbes: maybe, need to play with it
dmachi: I believe he already applied the patch
uhop: ok
dmachi: I'm happy to go look in and mess with it, but am mainly worried about creating the same problems this
was presumably changed to fix without knowing really what they were.
uhop: I took it from anonymous
dmachi: its clear from the ticket it was expected to be slower, so it wasn't being done for peformance reasons.
Its just a lot slower than original noted in that ticket (the size of the dom was probably not big enough to
excercise it)
dmachi: uhop: I'll take a look this weekend and see if i can do it anotherway without breaking anything and send
you my results for review.
uhop: cool
dmachi: not promising anything, but i'll look anyway
wildbill: hi all, sorry i missed the meeting, alarm didn't make any noise
kgf: http://higginsforpresident.net/~phenny/dojo-meeting.txt
21
wildbill: thanks
kgf: uhop took ownership of the perf ticket 'cause it was currently anonymous
chrism1: hi bill
kgf: I think someone was under the impression you might've already checked in the one thing you'd already tried
chrism1: other than the arrow position on tooltipdialog, are there any other reasons why the current trunk
version shouldn't be used for mobile popups for things like date pickers, color pickers, etc?
chrism1: if the styling gets done for mobile themes
wildbill: he can work on it if he wants but i wanted to check w/him i guess he's not here now
wildbill: he also grabbed some other tickets but they are still marked TBD
kgf: better than 'future'? lol
kgf: he probably grabbed the IE9 ones?
kgf: pretty sure he's aware of the push for that in 1.6.1/1.7
wildbill: not sure where this log starts, hard to read these timestamps
uhop: he is here
uhop: chatting with you ( wildbill ) in #dojo
uhop: kgf: seriously, I am unclear on labels, if you are so up on that, just explain how to mark tickets
wildbill: uhop oh ok i see your messages there. thx for looking at the parser, you won't be able to remove the
recursion though w/out breaking functionality
uhop: why?
kgf: wildbill: perf thing only really came up within the last 30 or so lines. meeting started around 1300915805.94
wildbill: thx
uhop: so what is it? tbd? future? 1.6.1? I didn't change it
kgf: uhop: actually I'm still a bit confused on the labels myself, I was more wondering what's right if both future
and tbd are wrong
uhop: or should it be anonymous until fixed?
wildbill: about the labels, for the IE9 bugs i thought we wanted to fix them in 1.9.1, yes?
kgf: I assume anything IE9 related should be 1.6.1
uhop: IMHO, if nobody has better idea, lets continue with anarchy --- it worked for us before without problems
kgf: for the parser one...1.5.1? 1.6.1?
uhop: wildbill: what if some stuff cannot be in 1.6.1?
uhop: e.g., it takes too long
wildbill: well, whenever possible
wildbill: not sure what you are asking
22
uhop: so should I put 1.6.1 and bump up later, or 1.7 and bump down, when fixed?
kgf: e.g. do we bump ticets' milestones at RC or something
wildbill: oh, you should put the milestone you are planning on
kgf: this is relevant to my interests, I tend to leave tbd until I know where I'm checking it in for sure but I'll start
being more proactive if I know which way we tend to roll
uhop: wildbill: no, I just want clarifications on "wildbill
he also grabbed some other tickets but they are still
marked TBD"
uhop: how they should be marked?
uhop: or was it wrong to grab anonymous and sjmiles tickets?
wildbill: well, I'd say to mark them for 1.6.1 because there's >80% chance we'll fix them in 1.6.1
uhop: wildbill: "you won't be able to remove the recursion though w/out breaking functionality" --- "why?"
wildbill: ok, the recursion is there for a couple reasons, one is the stopParser: true flag used on ContentPanes,
where it doesn't parse certain subtrees, and another is for propagating dir and lang
uhop: so?
wildbill: how else would you do it w/out recursion?
wildbill: ("it' meaning stopParser and dir/lang)
uhop: we can walk DOM in non-recursive fashion --- it was done that way purposely
uhop: that's why every node has parent
uhop: even explicit stack is not required
wildbill: sure, that's true, but doesn't it go from O(n) to O(n log n) or something like that?
uhop: nope
wildbill: so it stays at O(n)?
uhop: much faster --- instead of multiple stack frames (=> closures) --- simple iterations
wildbill: ok, let's go over the math and see which one of us is miscalculating
uhop: yes O(n), where n is a number of nodes in the subtree
uhop: it would be easier to fix it and see if the fix works
uhop: the proof is always in the pudding
wildbill: yes feel free to fix it as long as your fix passes the regression tests in dijit. i'm assuming worst case
where for every node we have to follow the parent up to BODY
wildbill: admittedly, there are a lot of variables, like what percentage of nodes have a dojoType specified
uhop: apparently dmachi wrote perf tests already, so I am going to use them first to see if there is any
improvement
wildbill: that's a bit silly, his performance tests don't have any widgets on the page
uhop:
uhop: still it is a valid case
uhop:
23
wildbill: agreed
uhop: ok, got to go
wildbill: so just to be clear though, if every node had a dojotype and we have to trace parent pointers up to
BODY for each node.
chrism1: hi wildbill
chrism1: ^^^ q re: tooltip dlg and mobile
wildbill: hi
wildbill: kgf: thanks for the tip, reading from 1300915805.94 now
chrism1: trying to figure out if more refactoring needs to be done, or whether we can try using tooltip dialog for
popups on things like mobile datepicker, selects
kgf: wildbill: np
wildbill: chrism1: well iPad and iPhone are different beasts, i think it makes sense for iPad
chrism1: y
chrism1: iphone typically slides up or in from right a separate view
chrism1: with Done|cancel
chrism1: were ipad/tablet pops up
wildbill: haven't noticed the animation but I know it goes full screen like a dijit.Dialog
wildbill: i'm thinking of for example a Calendar popup or the "move to folder" dialog in gmail
chrism1: so the actual popup mechanism is different based on screen size
wildbill: yes, i think so, don't you agree?
chrism1: y
chrism1: but for the ipad/tablet case, do you think tooltip dialog can pretty much be used as is?
wildbill: i think so
chrism1: just re-style to match mobile device
chrism1: ok
chrism1: trying to see how much remaining work for that piece
wildbill: yeah, dmachi said he'd work on getting the arrow and popup centered rather than right/left aligned
chrism1: cool
wildbill: i should assign the ticket you wrote to him
chrism1: y
chrism1: where should the screensize->popup mechanism code live?
chrism1: in one of the dijit base classes?
chrism1: the piece that slides in a view, vs pops up a dialog
wildbill: hmm, i'm not sure, probably in dojox.mobile
chrism1: i c that ComboBoxMenuMixin is in dojox.mobile
chrism1: that should probably leverage this logic as well
wildbill: well combobox is special, it operates the same on iphone/ipad
24
wildbill: because you need to show the keyboard and the dropdown simultaneously
chrism1: k, what about a scrollable list that pops up in a dialog or view
chrism1: Select
chrism1: or multiselect with large # items
wildbill: that's different, it should presumably use the spinner code that ykami checked in
wildbill: on iPhone and a TooltipDialog on ipad
chrism1: right
chrism1: spinner code is a "slide in from bottom" view
wildbill: agreed…. when you said "slide in" before though what were you talking about? when i mentioned
calendar i meant the calendar that is a table, not the spinner calendar
chrism1: well, it could be either
chrism1: pick a date, using a calendar
chrism1: or via spinwheel
wildbill: right, sure
chrism1: calendar would slide in a view, same for spinwheel
chrism1: on phone
chrism1: but on tablet, tooltip pupup
wildbill: not sure what you mean by "slide in a view"
chrism1: u have an iphone handy?
wildbill: yes
wildbill: on iPhone, calendar spinwheel and grid-calendar seem pretty different since spinwheel only covers the
bottom half of the screen, but grid-calendar is centered and covers nearly the whole screen
chrism1: in some apps, the developer chooses to slide the view with the spinner or control up from the bottom or
in from the right
chrism1: the view that's slid in may not entirely cover the previous view
wildbill: sure
chrism1: and typically has Done|Cancel buttons to return
chrism1: or tapping off of the slid in view on the orig panel may also do implicit Done
wildbill: yes, that's correct
chrism1: in the gallery demo that we've got running...
chrism1: http://chrism.dojotoolkit.org/dojo-samples/demos/mobile-gallery/demo.html
chrism1: the UI detects screen dimensions, and displays sidebar nav accordingly
chrism1: i think this popup logic should use the same core function
chrism1: to either slide in a view or popup a dialog
wildbill: sure
chrism1: so on the Forms demo, when i've got the window size small like a phone, the Birthday field will slide in
a date spin wheel from the bottom of screen
chrism1: but if i'm on a tablet, it will use tooltip dialog
chrism1: i guess this should be a mixin class in dojox.mobile
wildbill: yes, i understand
25
wildbill: and yes, probably a mixin that calls out to separate code depending on screen size
chrism1: ok, and that's not something you're working on on the dijit side
wildbill: right
chrism1: so i'll need a ticket for kami
chrism1: or doug
wildbill: yeah, we should have a ticket, not sure on the details, it's not for combobox
chrism1: seems like it could possibly be used for any kind of input field
chrism1: maybe not
chrism1: small subset more like
chrism1: dates, times, select lists, search hits
chrism1: color
wildbill: agree about dates, times, select list, color (or any drop down button)
chrism1: y
wildbill: not for "search hits" if by "search hits" you mean combobox
chrism1: if u have a search field, and start typing, and want to show user top hits found
chrism1: like in a url field
chrism1: filtering select
wildbill: the combobox, and it's a different beast than all the others because the drop down needs to appear at
the same time as the keyboard
chrism1: ttrenka: u still here?
chrism1: phenny, tell ttrenka: emmanuel wanted me to tell you he thinks #12315 is ready to integrate at this
point. No more enhancements planned for gauges beyond that for now
chrism1: bah she's not in this channel
chrism1: things still ok in jp where you're at?
wildbill: yah
26