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.