*Matt*:
Clean-up for LQT header conversion (L9), in code review S will follow up with questions A couple hygiene patches Next -- not sure? Can he help with the LQT script? We're not sure what Andrew's doing.
*Matthias*:
Worked on Event-logging (L1) -- it's WIP, but it would be good for Matt to review the approach. One question -- When you start to reply, it'll fetch the handlebar template & compile it -- there's a slight delay. Not certain of the approach there; it may break on really slow JS or slow machines. Will still be working on that today. By the end of the day, card should be pretty much ready. One question -- right now, it'll only log things with JS, the no-JS case isn't covered. Is that something we want to do? (No for now -- it can be done as a v2 if we need it.) This should be ready to start running next week.
*Erik*:
Yesterday -- fixed up LQT conversion script. Andrew had added features, but hadn't made Added transactionality. More bugs -- we're being too lenient with users. We're testing by going from one wiki to another, shouldn't be a problem in real use cases. Script is back into a working condition. Successfully importing everything again. Looks to be mostly there. J16 is close, and it is now preserving history (L6). What's left is mostly the redirects (L8). Could we possibly defer until we go bigger than OfficeWiki? (yes, let's put it off until it gets to TranslateWiki or another heavy-use wiki.) There's also a bug for Echo - mention notifications on PTwiki. S asks about L2 -- Collect usage data on current Flow deployments. We could start getting data pretty quickly. Erik will pick it up and get started on it.
*Shahyar*:
ToC: Working on 5 things we talked about yesterday -- 4 out of 5 are done, still working on scrolling to the right place in the ToC dropdown. This should be finished today. Danny wants to see the ones that are done on flow-tests. All ToC patches that don't say WIP will be good for review.
On 11/13/2014 01:55 PM, Danny Horn wrote:
Worked on Event-logging (L1) -- it's WIP, but it would be good for Matt to review the approach. One question -- When you start to reply, it'll fetch the handlebar template & compile it -- there's a slight delay. Not certain of the approach there; it may break on really slow JS or slow machines.
Can you explain the connection between this and the EventLogging? Is it some kind of race condition?
Could this be fixed by just calling FlowHandlebars.prototype.getTemplate on the template name before the user action (e.g. on ready). If I understand correctly, that will ensure the template is compiled by the time it returns, but not actually render anything.
One question -- right now, it'll only log things with JS, the no-JS case isn't covered. Is that something we want to do? (No for now -- it can be done as a v2 if we need it.)
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=51854 (if we want to know how many people use Flow with JS completely off).
Matt Flaschen
On 14 Nov 2014, at 20:01, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 11/13/2014 01:55 PM, Danny Horn wrote:
Worked on Event-logging (L1) -- it's WIP, but it would be good for Matt to review the approach. One question -- When you start to reply, it'll fetch the handlebar template & compile it -- there's a slight delay. Not certain of the approach there; it may break on really slow JS or slow machines.
Can you explain the connection between this and the EventLogging? Is it some kind of race condition?
The way I’ve done the EventLogging right now is by adding data-attributes on the nodes you want a log an event for, when clicked/focused. Because we want to track follow-up events in the same funnel (should still know funnel id & entrypoint), I’ve added a data-flow-eventlog-forward, which accepts selectors to other nodes that will “inherit” those details.
We could pass that data around in JS, but a lot of the code (preview, cancel) is generic & used for a couple of other things as well + the exact same reply form is used for 3 entrypoints (reply-top, reply-post & reply-bottom). This would just have gotten messy.
Back to those data-attributes & forwarding: once an event is logged (e.g. start a reply), it needs to “forward” some details to other nodes we may want to log next (e.g. cancel, submit, preview). At that exact point, they might not exist yet: a interactiveHandler can still be working on them, fetching data from API, compiling the template, … Right now I just assume all of that work will usually be done in <50ms && not .flow-api-inprogress. It’s slightly error-prone, though. Ideally, we would execute this forwarding right after all interactiveHandlers, but due to their async nature (they could be doing API requests and stuff), that’d be messy too. Also see the comment starting at L534 in https://gerrit.wikimedia.org/r/#/c/171791/10/modules/engine/components/commo... https://gerrit.wikimedia.org/r/#/c/171791/10/modules/engine/components/common/flow-component-events.js
Anyway, TL;DR: it’s currently the best I could think of that doesn’t require adding callbacks & stuff in too many other places. I’m very much open for other suggestions, though!
Could this be fixed by just calling FlowHandlebars.prototype.getTemplate on the template name before the user action (e.g. on ready). If I understand correctly, that will ensure the template is compiled by the time it returns, but not actually render anything.
One question -- right now, it'll only log things with JS, the no-JS case isn't covered. Is that something we want to do? (No for now -- it can be done as a v2 if we need it.)
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=51854 (if we want to know how many people use Flow with JS completely off).
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee