Home » RADICORE » How To » Search when some columns are dropdown lists
|
|
Re: Search when some columns are dropdown lists [message #526 is a reply to message #517] |
Wed, 10 January 2007 12:03   |
David Lee
Messages: 44 Registered: June 2006
|
Member |
|
|
Having finally installed a debugger and found some more time, in file include.xml.php4.inc at line 302, array_key_exists($field, $fieldspec) evaluates as false, skipping the add blank entry code!
The reason is that my lookup table has the key location_id, but the main table field is fklocation_id.
This practice of prefixing foreign table indexes with fk comes from using the QSEE-Superlite program, which I, being a novice in the database world, found very useful for creating the entity relationship diagrams, and then the database structure from those diagrams.
To solve this problem, the first need is to confirm is Radicore should work with this naming convention, or if this breaks the design rules.
That should be easy for you to confirm, Tony!
Regards
David Lee
|
|
|
|
Re: Search when some columns are dropdown lists [message #531 is a reply to message #517] |
Wed, 10 January 2007 15:32   |
David Lee
Messages: 44 Registered: June 2006
|
Member |
|
|
As I understand it, the current code only adds the extra item to the list if $field is a key in the $fieldspec array. The keys of the fieldspec array come from the main table to be displayed, and, in my case include fklocation_id. However, the $field comes from the lookup table, and, in my case, is location_id. Therefore, the extra item will not be added, and will only be added if I renamed my fklocation_id column to location_id.
This, according to the previous post, should not be needed, and is therefore a bug in the code.
The value of location_id does appear as a lower level in the $fieldspec data structure, as the name of the optionlist for fklocation_id. Should the code check for this variable?
At present I do not understand why this check is in the code at all, but there is probably a very good reason for it, and I would not want to try altering it without understanding that reason!
|
|
|
|
|
|
Re: Search when some columns are dropdown lists [message #537 is a reply to message #517] |
Thu, 11 January 2007 14:06   |
David Lee
Messages: 44 Registered: June 2006
|
Member |
|
|
This post is mainly to help any others who come down this same track, rather than pursing any further options.
As my lookup array comes from another table, this implies that to use this functionality I need to
1) Modify the MySQL field name on that table to fklocation_id
2) Re-import the table into radicore
3) Re-setup the realtionships
4) Export the dictionary for that table
5) Edited any scripts that reference the old field name
Rather more work than I hoped, especially as in my complete system I have 6 tables which may be used as drop-down lists.
Maybe I should check out two other possibilities I vaguely remember appearing in the documentation:
1) Create a subclass with the modified field name - something like this was possible for handling some kind of name conflict
2) Can the GetExtraData routine be forced to return the array with the name of fklocation_id?
Thinking about the possible problems with those routes, I think I had better change the database field names, and keep to Tony's convention, which allows the system to fully work. Otherwise I may find similar problems elsewhere.
I did also try using a pop-up list, and found that such lists assume that the index field is a short form version of the item, and normally display that short form. I had not seen this documented anywhere, but as my index fields are numeric, caused me to drop that idea.
David Lee
|
|
|
|
Re: Search when some columns are dropdown lists [message #540 is a reply to message #517] |
Fri, 12 January 2007 18:17   |
David Lee
Messages: 44 Registered: June 2006
|
Member |
|
|
Point #1 was just making the two fields the same name - it does not matter if they are both "location_id" or "fklocation_id"
However, I have finally realised what you were saying, and/or how to overcome this problem. It requires two small, matching changes:
1) In the data dictionary for the main table, column fklocation_id, the name of the option list should be fklocation_id, not location_id. The updated structure needs exporting to PHP after changing.
2) In the cm_getExtraData routine of the main table, the name of the key for the required array should be fklocation_id, not location_id
Having made those changes, the search dropdown list have the extra entry of "undefined"
Thanks for your help, Tony, and I hope this thread saves someone else some time!
David Lee
|
|
|
|
Goto Forum:
Current Time: Thu Jun 19 03:17:01 EDT 2025
Total time taken to generate the page: 0.07775 seconds
|