Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <10136443.OnBuAidq6I@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 09 Jan 2013 04:31:58 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: Request for opinions on my newbie approach Newsgroups: comp.lang.javascript References: Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 109 NNTP-Posting-Date: 09 Jan 2013 04:31:58 CET NNTP-Posting-Host: 0e9ed1f6.newsspool3.arcor-online.net X-Trace: DXC=8oRRXQ\ But now the time has come to move over, and after toying with several > other development tools and platforms, I decided to adopt HTML + > ECMASCRIPT + CSS on the client side and PHP for the server for any further > development. By contrast to HTML and CSS, ECMAScript is _not_ (no longer even partially) an acronym; do not write it all-uppercase. Also know that you are for the most part not using ECMAScript, but various implementations of ECMAScript, including JavaScript. [And the DOM is not part of any programming language (since more than a decade); it is a language-independent API.] > The way to go seems to be to "encapsulate" as much as possible the DOM in > order to be able to get it out of my "operative" code. You are on the right track. By encapsulating references to target DOM objects in native user-defined wrapper objects you are avoiding to augment host objects and all the problems that come with that. Compare JSX:widgets.js. > Today I wrote my first attempt at a Form class, These languages (on the client-side) so far use prototype-based inheritance only. There are no classes. “Object type” appears to be the term that fits best as it is used in the ECMAScript Specification. > that will encapsulate an HTML form and allow me to simplify the rest opf > the code. > > So far, this is all that I have done: > > > function Form(f) { > this.name = f.name; > > for (var i = 0; i < f.elements.length; i++) for (var i = 0, len = f.elements.length; i < len; ++i) > { > var e = f.elements[i]; > this[e.id] = e; Not a good idea. Keep in mind that 1. not all form controls (need to) have an ID; 2. your wrapper object has other properties at that level that could be overwritten if a form control has the same Unless you also wrap the child controls, you do not need this loop. > this.addEventHandler(e, "blur"); > this.addEventHandler(e, "focus"); This does not make sense as it is. You will not always have listeners for those events. > } > } > > Form.prototype.addEventHandler = function (dest, eventName) { > try { > dest.addEventListener(eventName, eval(dest.id + "_" + > eventName), > false); Avoid eval() – see the FAQ – and avoid globals. Your wrapper object can have properties for event listeners if necessary (see JSX:widgets.js). Also, addEventListener() does _not_ (always) throw exceptions if the event listener cannot be added. (A fundamental API design flaw if you ask me.) It only throws an exception in some implementations on some environments with some event types if the event type is not supported; but that is non- standard behavior (which is due to another fundamental API design flaw). > } > catch (e) {} > }; > > […] > I am a rather "lonely" coder. Are we not all (at first)? :) > So I decided to ask for your opinions to this approach before going too > much further. > > TIA for any comments. HTH > -- Signatures are to be delimited with a line containing only ”-- ”. Thanks to the outdated version of Outlook Express that you are using, the trailing space is trimmed as you send the message. See for details and workarounds. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.