Re: Clear all optgroups and options from a select list

darwinist wrote:
Richard Cornford wrote:
darwinist wrote:
Richard Cornford wrote:
<snip>
You have never actually said what this thing is
supposed to be for.

It's to demonstrate all you need to know to start
making your own web-based desktop system, or any
subset thereof (a windowed-based application, for
example).

Now there is a frightening notion.

Then you are easily frightened.

Or maybe I am familiar with the harm that follows form over-confidence
that it is a common symptom of individuals who have got beyond the
initial stages of starting to learn javascript, but mistake the ability
to make things that broadly 'work' for knowing javascript.

I didn't look at your actual code too
much,

This much is obvious from the rest of the post. Your
criticisms have some merit, but they would have taken
as long to write (even for a fast typist, which I assume
you are), as reading the majority of the application in
question. There is no need for you to read it, except
that your arguments would have better aim, and probably
would have been shorter as a result.

Elsewhere we have discussed the readability of source code. I looked at
your source code and the prospect of attempting to read it did not
appeal.

However, it is only really necessary to consider attempting to
understand a third party script is there is some prospect that it may be
useful in some way. Having verified that it did not satisfy basic
criteria for the stated task any additional attention directed towards
it would be wasted.

I just verified ... serious memory leak ... select
element issue, and ... could not drag one window over
the contents of another ...
<snip>
Those could be useful and aren't precluded or made overly
difficult by imposing a complex framework, like some html
windowing packages do. As I said it is to demonstrate all
you need to know to start making one yourself. A lot of
people who want to make web applications don't have the
encyclopedic knowledge of the specifications that you do,
and access to an encyclopedia isn't quite the same thing.

The knowledge and level of understanding someone should possess prior to
attempting the creation of a complex web application may be subject to
some debate, but not knowing how to position, move and size Element, and
nest an IFRAME within them, strikes me as not knowing enough. But it
would not be the absence of that specific knowledge that I would worry
about, rather the grasp of the bigger picture that could be expected to
come with acquiring that knowledge. You don't get from novice to someone
who should be allowed to work on web applications by being handled "all
you need to know" as pre-written code.

<snip>
It looks like it is indented to be the bases for an
in-browser windowing system for web-applications. It
doesn't look capable enough for any actual example of
such,

Under Help->Examples there are several working examples
for making windows, making objects draggable, a hello
world program, etc.

There is quite a gap between 'hello world' and a web
application multi-facetted enough to warrant a windowing
GUI.

"Hello World" is only the first example, as it should be.
The basic functionality of organising things in separate
windows is not that demanding on a browser, and a lot of
basic web-applications could benefit from it.

If you look at the current situation in web development you see a very
large number of people attempting to make AJAX web sites, seemingly only
because they can (and particularly because others have created
frameworks for them that make it even easier). This is the power of
fashion and the AJAX buzzword.

There is going to be a bit of an anti-AJAX back-lash soon, as was
indicated by an article in the (UK) Financial Times earlier in the week
about the security vulnerabilities (various forms of script insertion)
introduced by AJAX (none really introduced by AJAX as they all existed
before, but certainly all exposed more often by a growth in people
writing public sites that use AJAX). That article essentially blamed web
developers for increasingly using a technology that they did not
understand well enough to cover the security aspects of, and framework
authors for shielding them from that understanding.

Which is not to say that AJAX applications should not be created, it is
an ideal technology for Intranet applications and special purpose web
applications. But in many (probably most) cases doing something because
you can is not a good reason for doing it. For a start it goes against
the KISS principle (and when you don't understand the technology you are
using it is difficult to justify labelling the result 'simple') as much
of what has recently been done with AJAX had previously, and more
simply, been done with server-side technology. And then there is the
impact upon reliability, where an AXAX e-commerce site I looked at
recently was so tied up in technology that its author did not actually
understand that the result did not even work with non-default
installations of IE 6. Costing the owners of the site (who presumably
paid for it in good faith) an indeterminate proportion of their
potential income, where the traditional server-based approach to
e-commerce would have allowed them to take money of all their potential
customers (and an AJAX with clean degradation design would have allowed
them to have their cake and eat it too).

Some web applications would benefit from an in-browser windowing system
(I am working on one myself at the moment), but using one because you
can is likely to directly result in issues.

I'm sure you could make a better one that is free and
even more lightweight and efficient, but where is it?

If someone is about to shoot themselves in the foot handing them a
bigger gun is not doing them a favour.

<snip>
At least two well known IE bugs, but the number doesn't
matter as any one is sufficient to make the result viable
for use on Windows IE only Intranets, or multi-browser
Intranets that include IE (i.e. the actual market) for as
long as your "I'm not particularly interested in coding to
the bugs of a product whose manufacturers don't even pretend
it's good anymore" stands.

Do you know if they've fixed it in ie 7?

I don't know, but it is unlikely that they would all be fixed (IE 7 is
not a major re-write it is a series of bug fixes and tweaks and some of
those issues are so inherent in the architecture of IE that they would
take a major re-write to actually fix). But it doesn't' matter as IE 7
is only going to be available for XP and 2003 (and presumably
Microsoft's new OS) so it will take even longer for it to becomes
dominate than the couple of years it took IE 6 to outstrip IE 5.

it's fairly lightweight and quite
responsive in either major browser.

Maybe as it stands, but an actual application would be
expected to have something going on in those windows, which
is what will slow the total down.

Most of the content can be organised in separate documents
in iframes, which the browsers seem remarkably adept at
handling. The windowing is just for more versatile organisation.

That will not make a significant difference to the way IE slows down
when you accumulate thousands of objects in the system.

<snip>
It's meant as a free codebase. I've seen nothing really
that does all desktop-environment stuff in a short, free,
clear fashion. Most is heavy or proprietary, or both, and
most try to reinvent the wheel.

There is the dilemma; if you attempt to anticipate and
provide all that an application may need the result will
be 'heavy', and much of what is included will be unnecessary
in any real application, but so long as it is omitted all
you have is a demonstration that it is possible to drag and
re-size IFRAMEs in a container of some sort on a particular
set of browsers.

You may be surprised how much of a struggle it can be to a
novice javascript programmer.

Why, it is inevitable that I would have been a novice javascript
programmer myself at some point in the past?

Just the individual techniques required are
popular "how to" articles all over the web. Having
given liberal comments my attempt was to draw together a
set of practical how-tos. I can see as a connoisseur of
the language you are holding your nose up at it.

One of the consequences of having been a novice myself is that I have
some idea of what path leads from there to some sort of understanding of
the subject.

<snip>
... . I happen to consider that what "works" is very
important.

My long experience of people declaring that something "works" or
"doesn't work" on this group has diminished the significance of the
word. ...
<snip>
Indeed my standard should have been stated more explicitly.
Two main browsers =

But not sufficiently well in IE for actual applications.

as much of the desktop-share as any program written
for any specific operating system could hope to reach,
maybe more.

Much of the time people are declaring things to 'work' only because
they have not tested them vigorously/seriously. Indeed you don't
seem to have tried stressing your code much, as the two megabyte
memory leak in IE per window instance should have become evident
once you had opened and closed 100 windows or so.

Maybe I should just declare my bias and write "runs best in firefox,
you broken-software using cretins", and put a link to download firefox
on the page for anyone in danger of these bugs affecting them. At
least it's free and will probably run on their operating system, if
they're allowed to install it.

Javsacript specs are what browsers should implement,
but actual browser support is what programmers need
to worry about.

The two are far too interrelated for the specifications
to be dismissed in favour of studying implementations
(assuming you had access to, and time to study, all
browser implications). As far as the javascript
specification is concerned the implementations that
assert that they comply with ECMA 262 actually have
very few deviations from the specification (and mostly
insignificant ones) so knowing how a javascript engine
should be expected to behave is a very good guide to
99%+ of the actual behaviour of implementations,
including the ones that are unavailable for actual
testing.

Specifications are one half of what will work,

Specifications are what should work, and how it should work.

the other half is what has in fact been implemented
in enough popular browsers to rely on it in the wild.

That is the attitude that gets in the way of ever being able to write
cross-browser code.

It seems that moving windows around by reference rather
than ID would be a speed improvement and probably slightly
less code,

As in general whenever you can pass, access or store a
string value you can also pass, access or store an object
reference the use of string references just adds a layer
of needless complexity and a runtime overhead.

Thanks for the tip.

so you can rest-assured my application will reflect this
when I next have a play with it.

OK, but doesn't that make you suspect "all you need to know
to ..."

Finish the sentence you are quoting.
<snip>

You don't se the logic in questioning "all you need to know" when
additional information suggests changes?

Richard.


.

Relevant Pages

  • Re: Delphi - desktop, Web, or USB?
    ... something has to run these web applications as well. ... browser, using Java to provide the programmatic stuff (or use some ... A Windows Media Player replacement? ... I have Open Office running off my USB drive. ...
    (borland.public.delphi.non-technical)
  • Delphi - desktop, Web, or USB?
    ... Email and office applications can been replaced for smaller ... I've used both, and had some fun with the various Google bits and bobs, and although they will get the job done, they are annoyingly slow at times, and have a distinctly clunky (almost Windows 3.1) look and feel to them. ... The implication of this line of argument is that the multiple gigabytes of Vista and Mac OSX are completely unnecessary - all you need is a Web browser and an ultra-light kernel to host it on - something to look after the screen, ... Just how realistic is it to run an application like Word 2007, or Photoshop, from a USB stick on any computer you happen to be near, without touching the registry or "installing" anything? ...
    (borland.public.delphi.non-technical)
  • Re: [WEB SECURITY] The state of JavaScript Hacking
    ... that the Mozilla browser is vulnerable to any specific type of attack ... The Mozilla XUL is considered a true RIA ... Last but not least we have Microsoft with their XAML and WPF (Windows ... WPF will allow you to build Rich Internet Applications with XML, ...
    (Pen-Test)
  • Re: [WEB SECURITY] The state of JavaScript Hacking
    ... that the Mozilla browser is vulnerable to any specific type of attack ... The Mozilla XUL is considered a true RIA ... Last but not least we have Microsoft with their XAML and WPF (Windows ... WPF will allow you to build Rich Internet Applications with XML, ...
    (Bugtraq)
  • Re: Recoverd mahine from SP2 nightmare
    ... It contains advice ... using Windows XP "prettifications". ... applications you do not use. ... You should at least turn on the built in firewall. ...
    (microsoft.public.windowsupdate)