bug/incomplete code in getRecords default WHERE?
3 posts by 2 authors in: Forums > CMS Builder
Last Post: July 23, 2010 (RSS)
By mjkayson - July 23, 2010
Have just been fiddling with what seems to be a bug sparked by the getRecords function (in viewer_functions.php):
This is working in a site frontend, not within the CMS - it's a simple form that submits to update a table that is part of the CMS, so the $_REQUEST superglobal is populated with various ($_POST) details from the form, which I use in an UPDATE query but I don't want them used anywhere else.
When I call getRecords( ) and pass in a WHERE clause, after a little digging around what seems to happen is that it automatically adds in a default WHERE clause though the function _createDefaultWhereWithFormInput( ), viewer_functions.php line 216.
The arguments for this are ($schema, '', $options) - and it seems (though I didn't look at it too closely) as if the second argument should be populated in order to avoid this default WHERE being added. This is just a question really - I've worked around it by storing the $_REQUEST in a class property and then setting it to an empty array, which works fine - I was just wondering what the logic behind this default WHERE clause is as it currently stands.
This is working in a site frontend, not within the CMS - it's a simple form that submits to update a table that is part of the CMS, so the $_REQUEST superglobal is populated with various ($_POST) details from the form, which I use in an UPDATE query but I don't want them used anywhere else.
When I call getRecords( ) and pass in a WHERE clause, after a little digging around what seems to happen is that it automatically adds in a default WHERE clause though the function _createDefaultWhereWithFormInput( ), viewer_functions.php line 216.
The arguments for this are ($schema, '', $options) - and it seems (though I didn't look at it too closely) as if the second argument should be populated in order to avoid this default WHERE being added. This is just a question really - I've worked around it by storing the $_REQUEST in a class property and then setting it to an empty array, which works fine - I was just wondering what the logic behind this default WHERE clause is as it currently stands.
Re: [mjkayson] bug/incomplete code in getRecords default WHERE?
By Jason - July 23, 2010
Hi,
The purpose for the default WHERE clause is to allow CMS Builder to do automatic searching. If the name of a variable in the $_REQUEST array matches a field in the table being searched, it will be added as part of the WHERE clause. This is an extremely useful function, but sometimes causes a problem if you don't know it's there.
getRecords() does this by default, but you can tell it not to like this (example):
Setting 'allowSearch' to false will stop the function from automatically creating a WHERE clause, however, you can still add your own WHERE clause if you wish.
Hope this helps.
The purpose for the default WHERE clause is to allow CMS Builder to do automatic searching. If the name of a variable in the $_REQUEST array matches a field in the table being searched, it will be added as part of the WHERE clause. This is an extremely useful function, but sometimes causes a problem if you don't know it's there.
getRecords() does this by default, but you can tell it not to like this (example):
list($newsRecords,$newsMetaData)=getRecords(array(
'tableName' => 'news',
'allowSearch' => false,
));Setting 'allowSearch' to false will stop the function from automatically creating a WHERE clause, however, you can still add your own WHERE clause if you wish.
Hope this helps.
---------------------------------------------------
Jason Sauchuk - Project Manager
interactivetools.com
Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/
Jason Sauchuk - Project Manager
interactivetools.com
Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/
Re: [Jason] bug/incomplete code in getRecords default WHERE?
By mjkayson - July 23, 2010
ok great, thanks!