Reusable Libraries: Good or Evil?

J

Jim Ley

Definitely!
Telling if a form field is blank isn't as straight-forward as it should be.
You have to use different methods depending on if the field is a text input,
select box, multi-select box, radio button, or checkbox. And even more code
if it's a collection of inputs with the same name. Or hell, what if there
are 2 checkboxes, 2 input boxes, and 2 select boxes of the same name? :)

Ah, so that's loads of extra code (and potential for errors in unusual
browsers) so that people can check if radio buttons are blank, that's
not something that it makes much sense doing IMO. That's what I'm
against - "Here's some code which is how to test a X field is
something, a Y field is something etc. etc. pick the relevant one." is
my approach to that, it doesn't use a library, it uses code snippets.
Sounds like a perfect situation to develop a tree code library, and another
drag-n-drop tree code library which extends the first. Then you can use the
plain tree when it's needed, or the drag-n-drop version when it's needed,
without code duplication and without unnecessary code bloat.

No because to develop the generic solution would cost me many orders
of magnitude more time than the specific, the generic also still
wouldn't be what I wanted next time, so I'd need to produce a 3rd
library - drag-n-drop with tooltips, highlighting and radio button
like memory. Every time the requirements change, the implementation
is going to have to change, which leads the libraries to get more and
more bloated, and makes the testing much more rigorous - you're going
to start to have the library itself properly tested for regression
errors etc. - and as we don't have any real xUnit like tools for JS,
testing is expensive.
I'm still not quite understanding how you differentiate between "code
snippets" and "library".

One has a public interface documented for use, the other is a load of
javascript code for the author to put together.

A ready meal, or a pile of half made ingredients.

Jim.
 
R

Randy Webb

Matt said:
Not necessarily. There's no rule that says a commercial product or web site
needs to cater to everyone.

The ADA (and its counterparts) say different. And the lawyers think so
too. American Airlines settled a lawsuit not long ago in Florida for
around 5 million US dollars, brought by a blind man, whose reader
couldn't handle the webpage. He had to call on the telephone. His
tickets cost him 20 dollars or so more, he sued and won.

The culprit? AIUI, a javascript dependency.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Of course, the ADA doesn't apply to everyone or every situation.

Agreed. But it is a codification of principles of considerate action
which should be applied much more widely than merely as codified.

A Web site should be accessible to all who might reasonably be
interested in reading it, without imposing fonts or colours which may
make it unreadable, without requiring specific browsers, etc., and
without wasting bandwidth.

Jim has written about low-bandwidth links; but IIRC he has not added
that while Web pages are being fetched there may well be other link
traffic - the hardware bandwidth may overestimate what is conveniently
available.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top