Difference between revisions of "Extension talk:RecordAdmin"
(notes about how you might implement server side validation) |
(→Validation: whats wrong with JS?) |
||
Line 28: | Line 28: | ||
Not sure how to pass the data to the eval. The namespace containing the php validation code would need to be protected also. | Not sure how to pass the data to the eval. The namespace containing the php validation code would need to be protected also. | ||
--[[User:Rob|Rob]] 13:41, 1 March 2009 (NZDT) | --[[User:Rob|Rob]] 13:41, 1 March 2009 (NZDT) | ||
+ | :Why is server-side validation better anyway? I don't see the benefit in adding that complexity when JS is the usual solution and offloads the job onto the client. If people are worried about security they should use https. --[[User:Nad|nad]] 17:41, 1 March 2009 (NZDT) |
Revision as of 04:41, 1 March 2009
Contents
Search
The member search form works like a filter, so leaving it completely empty and then clicking search will list all members. Filling in some characters such as 123 into the phone field, then clicking search will list all members having 123 in their phone number somewhere. The fields in the search form are regular expressions, so more advanced searches can be done, for example putting ^445 into the phone field will search for all members whose phone number starts with "445".
In the search results list, click edit to change any properties of the member, or click on a results title to go to that member's article to delete it or see its history etc.
Wikitext content
Some fields - especially (only) textareas need to have their content interpreted as wikitext.
SubForms
The next thing we need is for RecordAdmin to be able to handle sub forms for fields that link to other records. Instead of selecting from existing records, the form for the records linked to is edited directly inline. This requires firstly a parser-function which can render the inline forms along with JS for show/hide and later AJAX, and secondly the ability to process and remove the sub-form values from the posted data.
Validation
need Serverside validation, I think it would be better (more robust) than Client/JS.
- I think the only way to do this to cover all cases would be to supply a php validation function say Validation:MyForm. The extension could then pass the form data to the function and give it the opportunity to pass or fail the input and give error text. Not sure how this would integrate with the current extension exactly. Maybe: Valigation:Myform would be something like:
function wpFormValidate($data) { if( $data['name'] != '') { $result = false; $message = 'Name is required.'; } else $result = true; return array( $result, $message); }
Not sure how to pass the data to the eval. The namespace containing the php validation code would need to be protected also. --Rob 13:41, 1 March 2009 (NZDT)
- Why is server-side validation better anyway? I don't see the benefit in adding that complexity when JS is the usual solution and offloads the job onto the client. If people are worried about security they should use https. --nad 17:41, 1 March 2009 (NZDT)