Status report on Preview/Spellcheck
I really thought I was going to have it done long before now. After all, the hardest part was done in a few hours.
The old axiom of the last 20% of a project taking 80% of the time sure caught up to me on this one.
Short version: It's not ready yet and though I'm going to try to work on it this weekend, I'm not optimistic I'll get done with it that soon.
Long version: The "hardest" part, one would think, would be the queries to check every word of a potentially thousand-word document and make a list of every one of them that isn't found in our 250k-word dictionary. And do so very quickly. Especially since you can't work with "text" field types in SQL Server queries and instead need to split up large messages into multiple 8000-character chunks, through quite a bit of trickery. As Dave said, the queries for this give him a headache when he tries to read them.
That was done in no time, thanks in large part to the magic of cut and paste (read: "steal from iHub")
What's proving to be the trickiest part to deal with, just as it was on iHub (and it's still a bit buggy there) is dealing with the multiple entry and exit points and scenarios possible for the Previewer. Did the Previewer get entered via a Private or Public message compose routine? Or the Edit screen? Is the previewed message a reply to another message? Is the message being replied to a public one or private? Based on all those entry scenarios, where do we go when the user selects "Edit" from the Preview screen? Where do we go if they selected "Submit As-Is"?
Where I'm at right now is that I can compose a very long message and Preview it. It gives me a nice list of all the possible typo words and also bolds and underscores them in the preview. And when I select "Edit", I'm taken to the existing Edit routine, with the edit box populated with the original message, and a list of typos above the box.
And that's it so far. Seems like a lot, and it is. But there's a lot of work left to do. Lots of variables that need to be stored with the previewed message so I know where Preview was called from and can redirect appropriately. Lots (I mean LOTS) of editing of existing routines (I prefer this to creating new routines) so that they can deal with being called from the Previewer in addition to the other methods currently used.
The number of scenarios to account for goes up exponentially with each possible entry point to the Previewer.
There're a bunch of them.
But I wanted to let everyone know that I am actively working on it and it's the only project I'm working on right now when I'm able to devote time to programming.
I'll try to work on it some this weekend, but I'm definitely not getting it implemented today as I'd thought. I certainly should be able to get it done next week, though, then I can knock out a few of the smaller items I'm sure have accumulated (some of which are written down in my ever-present spiral-bound) for a day, then shift my focus to the "Ignore" feature, which at this point is sounding comparatively easy. |
