It looks as though search_instructions.inc is no longer needed. Check on this, and delete it from the repo if that's the case.
Currently, memory and time settings are in db/connect.php, which is a generic file shared by all projects. This requires modification of the file if a particular project has different requirements, which puts its working copy out of sync with the repo. Instead, these lines should be moved somewhere else -- possibly into local_classes.php:
I've updated the instructions in the sample file to include all the new features.
I've been rolling out the latest version to some of the existing projects. So far, Manifestoes has the current code, as does JSRDocs (as of today); VPN dev has it, but I haven't moved it to VPN yet. Properties will be the last one I do, I think.
This was not major, just an annoying GUI behaviour:
It turned out that I wasn't sending the search filter parameters along with the record update data. That's now being done.
Started detailed bug-testing:
Linkset fields now shorten their link text around an ellipsis by default (default max length is 60). Preliminary testing confirms that everything works on FF, Chrome, Opera and IE9. I'm not testing with earlier IEs.
Found the bug, eventually -- it was a lesson I've learned before, and forgotten: you can't use a period in the name of a request parameter. It has to be underscores.
I've done a couple of other tweaks, and now I'm going to roll it out to the dev version of the Manifestoes db and do serious testing on various browsers.
Multiple-record editing is now basically working, but I have one more problem to solve:
When you submit an edit form for an existing single record, for each one-to-many field, all existing records in the linking table are deleted, then new ones are created if there are any new ones in the submission; otherwise, none are left. In the case of a multi-record edit, though, we have a complex situation because if the one-to-many field is enabled, but no items are in it, then the intention is to delete all link records relating to all the records being edited. However, when the MdhRecord object reads data from the submission, it finds no parameters relating to the one-to-many field, because no selections were made, so it (currently) concludes that the field was not "set", and does nothing, leaving all the existing link records in place.
I need to find a way to submit the fact that the one-to-many field is selected even though there are no data items for it. This might be achieved by reading the disabled attribute of the hidden generic select control which is used to clone new selects when you add new items to the field. The disabled state of this control should reflect the disabled state of the field itself, so I should be able to send a flag based on this which the one-to-many control can read.
Once that's done, there will be extensive cross-browser testing to do, and then I want to complete a couple more tweaks: saving the state of the table display controls as cookies, and elliding URLs in MdhLinkField and MdhLinkSetField.
I've puzzled for a while with the issue of how to serve up a file type for download, with a suggested extension that's different from .php, from a .php module on the server. Turns out it's perfectly simple:
header("Content-type: application/csv"); header("Content-Disposition: attachment; filename=file.csv"); header("Pragma: no-cache");
I've added that to the get_search_as_spreadsheet.php module, and it works fine. Another annoyance fixed.
All field types are now working in the multi-edit GUI. I've also fixed up some display issues in the one-to-many field, which were caused by working around a bug in webkit; after deleting a one-to-many item, a linebreak would be left in place, which was a big ugly.
Next I have to get the back-end code working...
This project aims to design a flexible online database which can be set up as very quickly for a researcher requiring a relational database, and is easy to modify and extend. The Web GUI provides tools for data-entry in as simple and convenient a manner as possible, while also allowing data-integrity checks. The application development sandbox is currently at https://hcmc.uvic.ca/people/martin/potluck/editor/index.php; and half a dozen UVic projects are already using the codebase. The code is managed through SVN here: https://revision.tapor.uvic.ca/svn/adaptivedb/.
|<< <||> >>|