Hi, I got yet another question.
I can't find anything about how the validaition works. How do you write demands for it?

An another note, in the demo database there are made some dropdowns. And therefore is easy to see how you can do this, but how do you make checkboxes and radio fields?

What do you mean "how validation works" ? That's an internal table, and you don't modify it directly.

Look at the search page for how to do check boxes. If you mean how do you make a set of choices from the database radio buttons or check boxes rather than a drop down list... I'm not sure. I don't know if that is built in to LinkSQL the way the drop down is. CGI.pm allows all sorts of stuff... it's simply a matter of calling it.

You can make any field a select list, checkbox or radio buttons by editing the .def files. This only automatically affects the admin area though.

Cheers,

Alex

What I meant about checkboxes etc. was as follows. The demo says in links.def: "%db_select_fields = (" as "isChanged => 'Yes,No'". What do you write in "%db_checkbox_fields = (".

About the validation "'^\d{4}\-\d{2}\-\d{2}\s*\d{2}\:\d{2}\:\d{2}$'" for example. I don't know what this means. I would to have more basicly knowledge about the validation field. There must some documentation somewhere.

The validation field is a simple REGEX (regular Expression) You can use any of the many references -- I can't find the book here, but there is an Oreilly book on regex's

It's a standard form of pattern matching.

I would imagine the same thing --- the field you want to have the check boxes from and the paremter list. Use the same format.

Alex -- why can't we use these in the templates? Is it just a matter of moving a routine around to handle it? Or is there another reason? This is being handled through CGI.pm I assume.

No, CGI.pm is not used for this. You'll find all these in DBSQL.pm. You do:

my $select = $db->build_select_field ('Column Name', 'Selected Value');

or

my $checkbox = $db->build_checkbox_field ('Column Name', 'Values');

and you'll have the html in $select or $checkbox.

Cheers,

Alex

Ok, so how does the "admin.cgi" know that the field has a drop down list?

This would only affect the "modify" and "add" cgi programs (and the users) since that's the only time you are inputting data to the database. All the other templates read what's already there, and spit it back.

Question 1: Would it be difficult to modify these scripts to automatically work like the admin area?

The reason is that it would eliminate one more source of upgrade/update errors in the program by keeping the templates "templates" with as little hard-coded data as possible.

Problem 1a: This then brings me back to the issue of local defaults overriding the built-in system ones in the .def file. This is a more complex logic problem, but if the .def file is resynced, the local changes are lost (weight, validation, etc). Maybe resync could preserve the original .def file and only insert the changes for added/deleted fields, or changed ones. There could be another option "set to default values" that would set everything back to the 'generic' defaults -- which is basically what it does now. Search weights are the ones that trouble me the most since they cause the most problem if set back to 0.

Question 2: I haven't checked -- but does the resync feature detect all the "slection" fields, or do you have to manually add them to the list in the .def file? I seem to remember having to do that manually but I don't remember if it was after a resync or not.


I'm a little behind in updating the FAQ, but these are Q&A I'd want to add.


[This message has been edited by pugdog (edited December 22, 1999).]

The admin uses: $db->build_html_record_form and $db->build_html_record to generate what a record looks like, and what a form should look like.

It would be easy to add this into the add.cgi and modify.cgi, however most people wouldn't be happy with how it looks. Most people want to be able to control how the forms look, the fonts, the table layout, etc, and an auto generated form isn't worthwhile.

You could do it by adding:

my $form = $db->build_html_record_form()

and then using $form in the template though. What might be an idea is adding a new template link_form.html where people could outline what the form should look like. This would be used in add.html, add_error.html, modify.html, modify_error.html, and possibly maintain.html.

As for the .def files, re-syncing basically just looks at the mysql table and resets up the .def file. You will lose index weights, custom validations, etc. You will lose any selection/checkbox values that aren't defined as ENUM types in Mysql. I realize a better system is needed. =)

Cheers,

Alex