Events and Cells
Casey West
handling. Every keystroke entered is analyzed and computed. There's
something fishy about the current implementation of event handling at
the cell level: namely, it's incredibly intrusive on the HTML. I want
to make pressing TAB and, ultimately, pressing SHIFT+TAB Do The Right
Thing. In doing so, I want to change the way we attach events to
cells. Here is a simple description of what I intend.
Lets get Class-y
First, I want to collect cell-related JavaScript
into a class called `Sheet.Cell`. I want to do
this slowly, over time. It doesn't have to be a
large process. I'll start with the most important
cell-related function, `rc0()`.
(Don't worry, I'll rename it.)
Lets Get Too Attached
Second, I want to attach each event handler using
non-obtrusive JavaScript. For example, `rc0()` is
the handler for `onClick` in a cell. If I renamed
that function as `selectCell()`, and if I were
using MooTools, I'd connect to a cell like this:
$('A1').addEvent('click', selectCell);
Expand the Zoo
Over time, `Sheet.Cell` will collect all the cell
related JavaScript in the SocialCalc UI. Also,
event handlers will be attached directly to their
elements (when appropriate) which means we can
reduce the amount of editing-mode conditionals in
the interface code.
I'm going to begin down this path shortly. I await further comments.
--
Casey West
Tony Bowden
> I want to make pressing TAB and, ultimately, pressing SHIFT+TAB
> Do The Right Thing.
> into a class called `Sheet.Cell`. I want to do
> this slowly, over time.
> non-obtrusive JavaScript.
Does this require a bunch of supporting refactorings first before we can
use this approach? Or can we start down the path straightaway and then
gradually reimplement the existing stuff? For example, could we redo
today's "TAB" change to work like this on its own, or do we require
other rewrites first?
Tony
Casey West
On May 29, 2007, at 3:49 PM, Tony Bowden wrote:
> Does this require a bunch of supporting refactorings first before
> we can
> use this approach? Or can we start down the path straightaway and then
> gradually reimplement the existing stuff? For example, could we redo
> today's "TAB" change to work like this on its own, or do we require
> other rewrites first?
Lots of questions. Allow me to pick them apart.
> Does this require a bunch of supporting refactorings first before
> we can
> use this approach?
No.
> Or can we start down the path straightaway and then
> gradually reimplement the existing stuff?
Yes.
> For example, could we redo today's "TAB" change to work like this
> on its own, or do we require other rewrites first?
Great question!
The TAB version of this is more complicated than the `rc0()` version.
`rc0()` IS the event handler for `onClick` while the code to do
something with TAB exists within a function for handling keyboard
input on a slightly larger scale. So, the answers to questions one
and two still stand for this TAB work, but it'll take twice as long
(20 minutes instead of 10).
In very short, the answer to this question is: "on its own."
I imagine that's what you hoped. It gets slightly tricky only because
some event handlers seem to be bound to the window (essentially
capturing *everything* and reverse-engineering context) instead of
directly to the elements they want to pay attention to. So I may have
to tease a few things out, but that kind of refactoring isn't hard.
In those cases we might have instance A and instance B smashed
together. There's common code X that they both use, and I know how to
handle that situation.
--
Casey West
Tony Bowden
> (20 minutes instead of 10).
> In very short, the answer to this question is: "on its own."
> I imagine that's what you hoped.
Indeed so :)
Although I am actually a big fan of "refactoring for its own sake"
(anyone who knows me knows that I'm hardly a subscriber to "if it's not
broke, don't fix it"), I'm an even bigger fan of "refactoring with
intent". So having a target of "let's add TAB this way" (or shift-TAB,
or whatever the target really is), makes me even happier than a gradual
refactoring that will pay off at a later date.
Tony
Dan Bricklin
I don't have any special issues with using a library, nor with caching, as long as debugging is easy (edit, test without doing anything in the browser other than clicking on the re-edit page button). The Tab issue should take into account different browsers (especially the tough Safari) and tabbing within dialogs if we could (like the Sort dialog and around the buttons in the formula/command area at the top).
I hope we've made a list of what keyboard and mouse behaviors we want to put in and look to that before we implement. Some might be hard to retrofit once we code the new event handling. A spreadsheet can be keyboard intensive to use, so make sure we don't forget the keyboard -- the more like Excel, et al, the better. Google punted some of this and gives you errors if you are used to the keyboard ( i.e., more efficient) way of entering some things like formulas.
While we are trying to get a simple UI, as Excel shows, at some point you need the ability to give the full complexity of a dialog, such as that on the Format tab. Make sure we can do that. We should not depend upon people discovering short cuts. A full dialog box helps you survey the full capabilities of a product. While Google's engine is quite powerful, they initially did not expose a lot of what you can do and required you to export/import with Excel to do things. Like Excel, the Format tab reflects the attributes of the cell you are pointing to and updates as you move the cell cursor.
WRT the library, if it's MIT License, then I think it will be compatible with GPL and CPAL, but you might want to check. As long as we can provide the source in our release it should be OK with me.
I just hope that the code we end up with is easy for novice programmers to follow. I tried to use simple constructs and do at least some commenting. I think we should stay with a reasonable amount of comments.
-DanB
Casey West
On May 29, 2007, at 4:50 PM, Dan Bricklin wrote:
> I don't have any special issues with using a library, nor with
> caching, as long as debugging is easy (edit, test without doing
> anything in the browser other than clicking on the re-edit page
> button).
Excellent.
> The Tab issue should take into account different browsers
> (especially the tough Safari) and tabbing within dialogs if we
> could (like the Sort dialog and around the buttons in the formula/
> command area at the top).
I'm just working on pressing Tab within the context of cell selection.
> I hope we've made a list of what keyboard and mouse behaviors we
> want to put in and look to that before we implement.
We haven't made that list, yet. We're just working on a few obvious
cases to start, as improvements, and generally making it easier to
hack new input handling (from keyboard, mouse, etc).
> While we are trying to get a simple UI, as Excel shows, at some
> point you need the ability to give the full complexity of a dialog,
> such as that on the Format tab. Make sure we can do that. We should
> not depend upon people discovering short cuts. A full dialog box
> helps you survey the full capabilities of a product. While Google's
> engine is quite powerful, they initially did not expose a lot of
> what you can do and required you to export/import with Excel to do
> things. Like Excel, the Format tab reflects the attributes of the
> cell you are pointing to and updates as you move the cell cursor.
I have no idea how this is germane to the topic at hand.
> WRT the library, if it's MIT License, then I think it will be
> compatible with GPL and CPAL, but you might want to check. As long
> as we can provide the source in our release it should be OK with me.
As an interpreted language, the JavaScript source will be in our
release. It is a good idea to check that the MIT license is
compatible with CPAL, for the purposes of *distributing* MIT covered
code within a CPAL covered product.
> I just hope that the code we end up with is easy for novice
> programmers to follow. I tried to use simple constructs and do at
> least some commenting. I think we should stay with a reasonable
> amount of comments.
>
It's extremely important to me that the code we end up with is easy
to follow. As an expert Perl and JavaScript developer I've found the
SocialCalc code to be some of the most obtuse and obfuscated I've
ever worked with. I want to make that very much better.
--
Casey West
Dan Bricklin
I'm just working on pressing Tab within the context of cell selection.
> I hope we've made a list of what keyboard and mouse behaviors we
> want to put in and look to that before we implement.
We haven't made that list, yet. We're just working on a few obvious
cases to start, as improvements, and generally making it easier to
hack new input handling (from keyboard, mouse, etc).
> While we are trying to get a simple UI, as Excel shows, at some
> point you need the ability to give the full complexity of a dialog,
> such as that on the Format tab. Make sure we can do that. We should
> not depend upon people discovering short cuts. A full dialog box
> helps you survey the full capabilities of a product. While Google's
> engine is quite powerful, they initially did not expose a lot of
> what you can do and required you to export/import with Excel to do
> things. Like Excel, the Format tab reflects the attributes of the
> cell you are pointing to and updates as you move the cell cursor.
I have no idea how this is germane to the topic at hand.
It's extremely important to me that the code we end up with is easy
to follow. As an expert Perl and JavaScript developer I've found the
SocialCalc code to be some of the most obtuse and obfuscated I've
ever worked with. I want to make that very much better.