Prev: Outstandingly excellent JS drag-and-drop tutorial with working code
Next: Number list to display in the slide show
From: pete on 1 Jul 2010 05:50 On Jun 30, 7:07 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > pete wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Prototype.js was written by people who don't know javascript for people > >> who don't know javascript. People who don't know javascript are not > >> the best source of advice on designing systems that use javascript. > >> -- Richard Cornford, cljs, <f806at$ail$1$8300d...(a)news.demon.co.uk> > > > Prototype.js comes in for a lot of scorn these days, maybe with good > > reason. I've no idea about Prototype because posts in this group and > > elsewhere have warned me off it. > > > I hope you'll stop harping on this issue. [...] > > You do know what a signature is, don't you? Rest assured I'll keep it at > least as long as what I quote there remains true. > > PointedEars, murmuring "it must be the heat ..." > -- > realism: HTML 4.01 Strict > evangelism: XHTML 1.0 Strict > madness: XHTML 1.1 as application/xhtml+xml > -- Bjoern Hoehrmann Congratulations! You managed to reply to a post that I deleted about 20 secs after I sent it. It's not realistic or polite to quote a post that existed for a moment and then disappeared, imo. > You do know what a signature is, don't you? What?!!? Do you mean to disavow stuff just because it's in your sig? > Rest assured I'll keep it at least as long as what I quote there remains true. Oh, I see. You embrace it at your convenience :-) -- pete
From: Thomas 'PointedEars' Lahn on 1 Jul 2010 06:32 pete wrote: > Thomas 'PointedEars' Lahn wrote: >> pete wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> [Prototype.js sig quoting Richard Cornford] >> >> You do know what a signature is, don't you? Rest assured I'll keep it at >> least as long as what I quote there remains true. >> >> PointedEars, murmuring "it must be the heat ..." >> [...] > > Congratulations! You managed to reply to a post that I deleted about > 20 secs after I sent it. It's not realistic or polite to quote a post > that existed for a moment and then disappeared, imo. > [More Googlodyte whining] Deletion on Google Groups does not affect Usenet, and AFAICS you have not cancelled your message. Therefore, if you cannot send `Control: Cancel', it is best to followup with a correction. Likewise, if you send `Control: Cancel' or `Supersedes' using a newsreader, it might be a good idea to delete the old posting on Google Groups, too.¹ I am not responsible for your mistakes or your lack of education. Get yourself informed where you are posting to and what customs apply there, unless you want to be written off as a luser. You have been warned. HTH PointedEars ___________ ¹ I am trying to do that for the time being; how long anymore depends on to what extent overall Google Groups quality will descrease; they have now started to not even get MIME encodings right anymore; I am beginning to yearn for ye olde Dejanews. Getting old, I know. -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: pete on 1 Jul 2010 07:26
On Jun 30, 10:07 pm, RobG <rg...(a)iinet.net.au> wrote: > On Jun 30, 9:34 pm, pete <pete...(a)yahoo.com> wrote: > > > On Jun 27, 10:50 pm, RobG <rg...(a)iinet.net.au> wrote: > [...] > > > The code has basic drag functionality, but no "drop" functionality as > > > would be expected by a javascript developer looking for a drag-n- > > > *drop* tutorial. > > > Drop is kind of buried. It's realized in the OnMouseUp(e) event- > > handler function in the linked article: > > That function is more of a "dragging has stopped" function, it doesn't > provide any hooks to allow a user (developer) to do thinks like add > functions to call when dragging has stopped or identify if the dragged > element has been dropped over a drop target, and so on. Very true. As the author tells us: "This example only scratches the surface of drag and drop. [snip] Moreover, one often wants to drag from one place to another, instead of just randomly. [snip] Simplicity first! !! "Determining what elements one is dragging over is tricky, because the onmouseover event does not fire if the cursor is over the element being dragged." The author did as he said he would, imo: "Drag and drop is a topic that can be explored to great lengths somewhere else; all you need to know about it here is that you left-click-and-hold on one 'draggable element', and then move your mouse with the left button down: the element you clicked on follows your mouse." He then goes on to implement those three functions. I hope I'm wrong, but it /sounds/ like you are criticizing the article because it doesn't treat stuff outside its stated scope, sort of like criticizing an algebra I book because it ignores calculus. Maybe you mean only to suggest that one needs a lot more study to fully understand d-n-d, as I think, too. The author agrees: "This example only scratches the surface of drag and drop...." For me, who wanted to get drag-and-drop, however rudimentary, working on his web page, the article was right on. I can wait to perfect it later. Anyway. I appreciate the issues you raise, which all deserve study and a lot of thought. > > > Likely the author learned a lot in writing the article, but his education > > > is not complete (and likely never will be in regard to javascript). > > > Sorry, I don't quite get this. Are you telling the plight of many/most > > JS programmers? > > I'm not sure I'd call it a plight, more a condition. Javascript is a > constantly moving target, even if the underlying language and public > specifications like the W3C DOM stuff stood still, there are new > browsers coming out all the time with bigger, better, faster > implementations. Yes, yes, good! I thought you meant just that. It's a fascinating topic, this business of never being quite caught up, of always having some finite further distance to travel/learn, because the goal is always receding: the DOM will never stand still; browsers will always improve; Achilles will never catch the tortoise. > So it is the plight of anyone interested in writing javascript if > their objective is anything other than short term support for a small > number of current browsers. Yeah, but that /must/ be the objective for a developer who wants to get paid, right? The backstop is that today's javascript code will 'always' work (we trust). Even if advances make it obsolete, deprecated, dumb, despisèd and rejectèd, whatever. > Writing an article requires the author to study aspects of the topic > that they hadn't thought of before (often because of "dumb" questions > by novice readers - the kind that quickly expose the depth of the > authors knowledge), Aagghhh! Please! Don't remind me :-) > or thought they knew thoroughly but realised they > didn't. The process of researching and writing a lucid article is a > great learning experience and I suspect a reason why written > assignments are highly regarded as a teaching tool. Absolutely! We never know what we don't know. Also the reason that we gotta' code to learn to code. > It is probably also one reason why blogs are so popular - the authors > benefit as much as, or more than, the readers. For sure, and blogs are popular with me partly because I can have the pleasure of pontificating with relatively few of the consequences I can expect in, say, my kitchen :-) -- pete |