Re: removing last chrs (with different browsers giving different last chrs )

Gregor Kofler wrote:
Jerry Stuckle meinte:

Hey, it's *my* framework. If I have to share it (it's reasonably documentented, but I wrote it for me), then he/she can resort to Rex::INT_EXCL_ZERO or whatever. Regular expressions are an important component in most contemporary programming languages. If someone is either not willing or not capable of understanding _basic_ regular expressions, he/she shouldn't be a programmer in the first place.


And you are the only person who will ever look at it? You never installed it on a client's machine, for instance, and they might change programmers?

NEVER assume you will be the only person to ever look at something!

I don't - otherwise I would dump most of the documentation at all.


Documentation is just as important if you are going to be the only one to look at it. Will you remember what you did three years from now when you have to make mods?

It uses constants from a class - to find out what's going on, the user will have to find the documentation for that class and decipher the constants.

Not the easiest thing to do always.

Erm... Given a proper IDE it would be a CTRL left click. Jerry, what's that gonna be? If you want the last word - be my guest.


Define "proper IDE". I use IDE's - but I don't depend on them. Not everyone has one.

In fact, the best tool I've found for PHP programming is Crimson editor on Windows or vim on Linux. Much faster than any IDE.

The whole stuff looks like:
(a) create form template
(b) add form elements
(c) add validation rules
(d) validate
(e) check state and save, redirect, whatever

The "individual" code for each form is, say, 20 lines. Everything else is hidden in the classes of the framework. I suppose that is the *idea* of a framework. Validity of "normal" get parameters is defined as described. Nothing else to do. If they don't match, they are not set.


But you only make a cursory attempt at validating the data, so size is meaningless.

You're assuming a lot. No, I don't.

First of all, I don't have one function which tries to validate everything. For instance, if I want to validate an integer between 1 and 5, I will use something like:

$emsg = array();

$val1 = trim($_POST['val1']]);
if (strval(intval($val1)) != $val1)
$emsg [] = 'Value 1 is not a valid number';

This ensures the value is an integer and puts out a meaningful error message if it isn't.

JFTR it would look something like that:
$form->addRule('foo', array(1, 2, 3, 4, 5)); // or Rex::INT_EXCL_ZERO
The error message is in the form template and displayed automatically.


Which means even more code - now you're a lot more than the "20 lines" you bragged about.

And you also have to add all of the code in your classes - that's part of it. So it's not merely 20 lines.

It's not always necessary (or desired) to have everything in the database.

The original requirements might have been for 5 categories because that's all the owner ever considered having. But now he wants to add one more item. You have a choice - change two or three pages which use that category, or dozens of pages which access that table.

Right I get it from the db - I don't change anything at all.

"You doubt". But have nothing to back that up except your opinion.

If you insist: The extra query for the categories causes an extra execution between 0.2ms and 0.4ms. On the shared host between 0.5ms and 0.6ms. *I doubt* this will be an issue both for the server and the user expectancy. There's potential for optimization elsewhere.


"You doubt" again. Multiple that by a few dozen other unnecessary items times 100 page view per second on even a medium-busy server and it's going to add up - even on a dedicated server.

lot of factors are involved - and while ONE item may not seem like much - this could easily expand into DOZENS of additional columns (and even a few extra tables).

No. My databases are lean and efficient. And I always retrieve the columns I need, not all that are available. I've done database design for several years now, I've never run into the problem of DOZENS of additional columns, because of some negligence in the initial concept.


Not when you have extra, unnecessary data in them.

Good design is also about what NOT to put in a database.

Yes. But state flags are something I would definitely put into a database.


It depends on the requirements.

Which is entirely different from not validating a field. What don't YOU understand? Or are you just trying to change the subject because you don't have a response?

EOD. Have your last word.


Just pointing out you're now trying to change the subject.

Not from what I'm seeing. Never assume a "proper user". ALWAYS assume an "improper user".

The "improper user" gets the "generic error message".


Never assume a "proper user". ALWAYS assume an "improper user" and put out meaningful error messages. To do otherwise is just plain sloppy.

I don't know of a single large project I've ever been on (and some have had over 100 programmers for > 3 years) who would allow such sloppiness to go through.

A bug in your page; some who has an old version of the page cached or accesses it via cached pages in google. Some accessing the page (validly) via cURL functions. A bug in the browser.

"Bug in the browser!" Hilarious. "You must choose category 1-5, not 6!" But he picked category 3. Will drive him nuts.


Yep, browsers have bugs, also. So does HTML. So do a lot of things.

The list goes on and on. Just because you have an invalid value in a field does NOT mean you have a bot attempting to hack your system!

Yes, Jerry. Again: Have your last word.

Cheers, Gregor



OK, the last word - I find your lack of attention to detail to be lazy and sloppy. It shows incompetence on your part - or at least a lack of interest in quality. Any time I see a website put out such a message I know the owner just looked for the cheapest programmer he could find, without consideration for quality. Maybe even you.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: I cant believe how complex this Format SDK is...
    ... technologies from low level interrupt programming to high-level user ... Sorry for any offence but I disagree. ... I find the documentation more than sufficient. ... -- In looking at profiles, am I even looking in the right place? ...
    (microsoft.public.windowsmedia.sdk)
  • Re: I wonder if Windows REALLY support the C++ language
    ... >> samples, any interface, etc., anything that pertains to programming ... > The MS documentation covers all supported languages. ... > excludes Windows CE and various other stuff): ... so is the search time (and sometimes worse than linear ...
    (microsoft.public.vc.language)
  • Re: I wonder if Windows REALLY support the C++ language
    ... Just to borrow from data structures and programming world ... so is the search time (and sometimes worse ... > So should have been with MS’ documentation – that is, ... The distinction is between GUI and console programming, ...
    (microsoft.public.vc.language)
  • Re: Beware wildcards in Kill
    ... as we "float" up into the sphere of advanced programming, the base constructs of what all is created from gets lost in the fog of ... > that documentation is often written by "technical writers" ... > who lack any real technical depth, ... > The only reason I happen to know the stuff I just told you ...
    (microsoft.public.vb.syntax)
  • Re: Designing PHP applications
    ... The type of advice would depend much on your programming background. ... bonus, when your documentation is structured and organized, the better ... Have a look at CVS. ... expecially one that has a gallery module... ...
    (comp.lang.php)