|
Poznámky k chybe |
|
|
|
Just a short note. I suggest this API:
['js']['regexp'] = '...'
['js']['hint'] = 'An integer value required.'
['js']['whatever'] ...
Of course, ['js']['hint'] could be used also without ['js']['regexp']. |
|
|
|
hbernard
|
|
2004-01-16 13:27
|
|
A short question about API :
how ['js']['regexp'] is related with 'required' ?
Should 'required' a simple way to require a value ? Then, when js/regexp is set, it is automatically 'required' ?
Or is this an orthogonal API ? I mean if js/Regexp is set without 'required, user may enter an empty string or a string that matches the regexp ?
Have someone some ideas about this... ?
Then, I will make the patch (post 5.4 issue) |
|
|
|
|
i would make it separate. user will have to match bothe required (if set) and regexp (if set).
another case is that regexp can make field as if required. example is emails, where you search for @, so that the field cannot be empty. so 'required' is useless/redundant. |
|
|
|
hbernard
|
|
2004-01-16 15:18
|
|
OK, last question is :
what the meaning of the regexp :
(1) input must match this regexp
or (2) if regexp match, then alert user
this just a boolean negation.
What seems the more intuitive ? |
|
|
|
|
(1): "you've entered a stupid value. press OK to change it"
(2): "you've entered a stupid value. press OK to procceed and enter it into DB"
:-))) |
|
|
|
|
|
hbernard: of course the first one... seems to be more intuitive for me |
|
|
|
hbernard
|
|
2004-01-16 23:12
|
|
Uploaded patch hb-jsvalid2.diff which implements :
['js']['regexp'] which can be cummulative or alternative to 'required'
if regexp does not match then alert the user and go back to the input form.
['js']['hint'] is also implement. If set, its value is appended to all js alert()
this patch is also a (maybe clean, but certainly shorter) rewrite.
Less lines for more feature ;-) |
|
|
|
|
there are several types of js:
1. 'required' returns 1 or 0 (implemented)
2. regexp validation, returns 1 or 0 (patched)
3. js function to validate, return 1 or 0 (not implemented)
4. js input change, returns value (for example making hashes of passwords) (not implemented)
5. js to create input, returns value (for example date-picker) (not implemented)
can we think about implementing latter 3 ? i think 3. and 4. are quite easy, and 5. is partialy done. (if assuming that user will take care whether functions are correctly defined/included)
i am a real js begginer, so my comments might be a little ... unreal. correct me, please. |
|
|
|
|
I will suggest API change from ['required'] to ['js']['required'] and preserve ['required'] for some time.
Also add new documentation section "Input validation" after "Input restriction" and cover there all ['js'] related functions. |
|
|
|
|
Patch seems to be invalid:
It generates
----------------------------
return true;
}
// --></script>
----------------------------
when there is no required field. |
|
|
|
hbernard
|
|
2004-04-04 21:20
|
|
uploaded patch against fresh cvs.
It implements API above and correct the bug you reported last bugnote.
sample use :
...
'js' => Array( 'regexp' => '/\d{2}/', 'hint' => 'this must be a two digits value'),
...
['js']['required'] is implemented, ['required'] is preserved for BC.
Please also note that a regexp like the above cause the field to be required, But the following allow an empty set '/\d{0,2}/'
If it is ok, I just have to write the doc.
edited on: 2004-04-04 21:21 |
|
|
|
hbernard
|
|
2004-04-04 21:52
|
|
BTW, do you plan to implement a "use_deprecated" flag, in order to allow smoother API change
Release x.1 with API A
(CVS work with API A + API B - both API allowed)
Release x.2 with API B, API A still available when use_deprecated is set.
just an idea I saw in another free software project. |
|
|
|
|
Concerning to the regexp: if ['required'] is set, it basically means, that field value has to pass one test more (currently implemented test if value is non empty); thus your regexp /\d{2}/ should allow empty values, however /^\d{2}$/ should NOT alow empty values; more: /\d{2}/ with ['required'] set should NOT alow empty values -- I hope this behaviour is clean and correct; let me know if you agree.
Concerning to OLD API: for some time ['required'] will be preserved; so it will basically set ['js']['required']; however in some future releases we could make some configuration option enabling deprecated options; this is related also to ['select'] => ['input'] issues
I'm going to look, if your patch can go to CVS. |
|
|
|
hbernard
|
|
2004-04-04 22:51
|
|
a> thus your regexp /\d{2}/ should allow empty values,
No, it doesn't, because "empty value" doesn't have 2 digits inside, this is just a side effect of the regexp.
b> however /^\d{2}$/ should NOT alow empty values;
yes, that's OK
c> more: /\d{2}/ with ['required'] set should NOT alow empty values
yes that's OK, but this is just caused by the regexp
I'm not sure I understand what you want.
a & b seems not to be consistent/coherent. |
|
|
|
|
Commited into CVS.
Notes:
1. ['js']['required'] postponed; I will create procedure where all backward compatibility stuff will go. Than will be ['js']['required'] implemented.
2. We have to think, if ['js']['hint'] should not replace whole message in JavaScript popup. To get user more freedom about displayed text. Hm? |
|
|
|
|
Oh yes, sorry, I made mistake in point A. You are right.
More yesterday, because now I really have to go home (bus will not wait for me ;-)) |
|
|
|
|
New method created backward_compatibility() covering all the backward compatibility issues. See commit notes:
http://platon.sk/cvs/cvs.php/phpMyEdit/phpMyEdit.class.php.diff?r1=1.131&r2=1.132
The important fact for this bug report is, that ['js']['required'] is now properly working.
Remaining tasks:
1. Think about ['js']['hint']. See my note above.
2. Write documentation section (idea possibly also written above). |
|
|
|
|
The documentation is written. See attached file and please correct grammar and other issues.
New chapter "Input validation" was created. I'm not sure, if it is the right name, maybe "JavaScript validation" could be more exhaustive, since only JS is used for form validation and I wonder if anything else could be used for client-side form validation. :)
This chapter is before (not after) "Input restriction" chapter, because it seems to be more logic. |
|
|
|
|
|
OT: triggers can be used for input validation also (they can halt the insert/update process). in the forum, there is an example of before trigger that halts the insert process and displays insert form to correct the input. i will make some documentation after my computer starts to work again (burnt chip). |
|
|
|
hbernard
|
|
2004-04-13 12:41
|
|
[1. Think about ['js']['hint']. See my note above.]
I will take this one.
I see two APIs:
a- 'hint' overwrite the whole message.
b- 'hint+' is appended to hardcoded message
b is current behavior of 'hint'.
a is more flexible.
Avantage of b : message is still partially internationalized.
Both can be implemented, please tell me if it is worth the API addition, or if we should go with (a) |
|
|
|
|
michal: could be very nice example for new "Hints & Tips" section
hbernard: How about ['hint'], ['hint_prefix'] and ['hint_postfix'] as well. :) |
|
|
|
hbernard
|
|
2004-04-14 15:46
|
|
nepto : Question is :
1- simple API that override default hint
2- extended API with hint_prefix etc....
I'm finally not sure this is a good idea to have an API that won't be very often used.
Whatever your answer is, I will make the patch and update the documentation. |
|
|
|
|
I will suggest pure ['hint'].
However if you want ['hint+'], than it should be caled ['hint_postfix']. ['hint+'] is definitelly not a good name for this.
Once we have ['hint_postfix'], we should have also ['hint_prefix'].
I believe that ['hint'] overding default text is enough. |
|
|
|
|
|
another OT: should it be possible to use variable in 'help' or 'hint'. like "$name $label['must_number']", replace $name for field_name and $label[..] by something from (custom edited) language file. but substituting arrays.... |
|
|
|
hbernard
|
|
2004-04-14 17:37
|
|
uploaded jsvalid4.diff which make 'hint' override default message.
UPDATE : I forget : Documentation is correct.
About michal suggestion, I think that $name and language $label are available at "build" time, so this isn't useful to do substitution on the fly (in fact, this could be wasteful).
An helper function that would not be a class method could be useful for retrieving $labels. But this seems not to be current PME policy.
edited on: 2004-04-14 17:43 |
|
|
|
|
Fixed in CVS, thanks.
Connot close for now, because I need Doug to check docs.
Concerning to static method: I can imagine something like phpMyEdit::getLanguageValue($key, $lang), where key is for example "Please enter". It will returned and localized version according to $lang.
It seems that we need more of these static methods. For example one for the current page mode: phpMyEdit::getCurrentPage() returning fe. 'list', 'filter', 'change', etc.
But this belongs to another bug-report. |
|
|
|
|
Doug, thank you for your corrections.
Final version uploaded. |
|
|
|
hbernard
|
|
2004-04-16 15:31
|
|
|
So this is a resolved bug. (Commit + Doc) |
|