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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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


--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
.

Relevant Pages