|
|
Posted by ^reaper^ on 10/21/90 11:21
While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:wlOBe.70371$G8.8518@text.news.blueyonder.co.uk>:
> On 14/07/2005 23:41, ^reaper^ wrote:
>
> [snip]
>
>> Thanks for the input, Michael.
>
> You're welcome, though Mike will do. :)
Heh. You're lucky I called you Michael instead of Richard. ^_~
>> Wrt to the other (globals, arrays, and bears, oh my!), making the changes you
>> suggested makes little sense in context of requiring more complex
>> serverside processing.
>
> Moving to an Object instance is about as complicated as changing:
>
> ... = new Array(); or = [];
>
> to:
>
> ... = new Object(); or = {};
I'm still not seeing what it buys. If a numbered array were all that were
available (v keyed arrays), thus requiring iteration through the lits to
access a specific symbol, I could see some value. However, since teh array
has a built in hashing feature for direct access as well as teh iteration
feature for list walking, both of which are required, client side overhead
is kept at a minimum. Outside of /seeing/, codewise, a js Object instead of
a js Arrray (or teh diff bracket doohickies), it seems to be more of an
impl pref, than anything else. *shrug*
> I'd double check, but I can't seem to access anything at the moment, so
> I'd take that with a pince of salt for now if I were you.
I got a wild hair and decided to move all of my serverside output into a
domdocument object. It makes teh serverside code so much cleaner and easier
to read (no need for teh string concat or echo chit, w/trailing lfs). Not
to mention teh time it saves by ensuring all required closing tags (vs
having to explictly include them), properties, etc are created properly.
And width teh pretty-print feature, the resulting markup is much cleaner.
That, and if I get another wild hair and decide I wish to change teh doc
structure, it's a simply a matter of changing teh parent element to teh
child calls. Very nice, and much more maintenance friendly. But anyway...
teh page is back up and since I've a ton of other commitments for teh next
while, it should remain in its present fugly state for a bit. ^_~
> Creating a proper Map object would be more involved, yes, but a more
> robust solution.
Robust in what way? I mean, really. All that teh present js impl needs to
know /or/ care about are teh one-to-one symbol to plaintext paired value
relationships and teh one-to-many symbol to position relationships. With
the latter containing the tag id (not the actual xy position) of teh symbol
locations. It does not need to know (or do) anything other than update the
dom element data with the related plaintext value (as teh actual
positioning is managed by teh css).
Put another way, were I to decide tomorrow to arrange teh canvas symbols in
a spiral, teh zk.js would remain unchanged. If, however, I were to create a
complex mapping object (as you're so proposing, to compute location, etc),
I would lock myself into a particular layout, in this case, a 2d matrix.
And that's not to mention teh additional compute overhead, as well as
explicitly tying in to a specific dom obj type (such as teh table soln, you
mention in teh next section).
This btw, is but one example that I've seen occur repeatedly. In teh proc
of attempting to engage in 'so-called' best coding practices, /some/
individuals end up overcomplicating what requires nothing more than a
simple solution, thus resulting in code bloat and unnecessary compute
overhead. And yes, there are instances where object encapsulation is
perferable over a structured approach. Esp when you're dealing w/complex
fns, possible thread/data collisions, etc. This however isn't one of them.
>> Furhtermore, I'm not seeing where replacing the canvas overlay divs
>> with a table buys me anything.
>
> I like structure. Don't know about you. Using a table would also allow
> you to remove the id attributes as you could use the cells and rows
> collections to access the elements like an array. If the 'addresses' are
> computed server-side, rather than a long list of literal y0x0, y0x1,
> etc., this approach would be similar and the calculation could be
> performed on the client.
I like structure as well. And teh table is teh logical choice at first
glance. Recall, my earilier rendition was purely tables. With teh primary
diff to include cells for containing teh symbols. Teh big however is, it
works great /until/ you start futzing around with... say, the browser text
size options. If you check out the 340 cipher, for example. Click on teh
mask, and then change your text size (once to the smallest and once to the
largest), the result is noticable. At least wrt to teh menu table. As the
symbols end up being vertically skewed due to teh vertical table cell size
changes. Whereas, the 'mask' plaintext on teh canvas, which are explicitly
positioned using divs, while also growing and shrinking, retain their
positioning. For this reason, I will be replacing the menu table with divs
at some pt in teh future.
What it basically boils down to (as I've so noted), is tradeoffs. In this
instance, do I want nicely contained markup lang (which no one but perhaps
a handful of coders even bother to look at), with teh presentation layer
becoming skewed and basically looking more shitty than its original
presentation state? Or, do I aim for a reasonable layout that also supports
dynamic font sizes (and is therefore 'user friendly' for those who may have
vision impairments)? I will generally choose teh latter over teh former,
for obvious reasons.
>> Whereas for teh table, I would need to set row height and column
>> width for each cell (which is, of course also easily computed)
>
> Despite the comment in brackets, you seem to be painting that as more
> complicated than it is. As I recall, the symbol table is evenly spaced,
> so the columns would be of equal width, and you know exactly how high
> each row needs to be. As I see it, you don't need to do any calculations
> at all.
Not quite. See above. And also check out teh site. I'll leave it as is for
now, so you can see how wonky it gets when you change your browser text
size from teh lowest extreme to teh highest extreme. Put another way, yes,
I could computationally derive a vertical symbol spacing value that rest
somewhere in between teh min and max possible browser text choices (e.g.,
smallest & largest). However, teh number of iterations required (code mod
wise) to reach an a reasonable value in conjunction with teh fact that it
will still look like chit when changing browser text size (due to teh
dynamic vertical spacing) is ten shades of a waste of time afaics. Esp,
when I can just as easily utilize teh calcs I used for teh canvas divs,
without negatively impacting teh resulting layout should teh user choose to
change their browser text size.
Then again, I could always revert back to teh original and place each
symbol in table cells. That would certainly solve teh positiong bit.
Though, I'm not interested in degrading teh performance (e.g. additional
bandwidth req for dl'ing, worst case, 408 individual symbol graphics, when
it presently dl's 2 compressed canvas graphics). O_O
>> In fact, I did just such a thing for the menu (e.g., using a table
>> for teh overlay). As you can see, when viewing teh page in firefox,
>> the table ends up scrunched to the left (even with explicitly stated
>> table & column widths).
>
> The problem, as I said in my previous post, is that the positioned
> container DIV element doesn't have an explicit width. Without being able
> to see the markup again I can't say exactly why that's so.
Oh, that's right. I forgot about that. I suppose I could throw teh width
into teh div container... hang on, brb. Nope, still doesn't work. Though it
doesn't really matter afaics, as teh menu controls (e.g., save, refresh,
mask, rots, etc) which are contained in their own table, do wonky things as
well. That, and teh js does not appear to work with firefox eider.
Oh well... o_O
--
"Anyone can do any amount of work provided it isn't the work he's supposed
to be doing at the moment." -- Robert Benchley
Navigation:
[Reply to this message]
|