prado3 - Project Hosting on Google Code

Last 7 days Nov 15, 2009 issue 208 (TDbConnection.Charset not working properly) commented on by google...@pcforum.hu - If you want to reproduce the problem, it's obviously important NOT to have the default charset already set to UTF-8 in your MySQL config, as that will make the "SET NAMES" and "SET CHARACTER SET" commands - and the difference in their exhibited behaviour - practically ineffective. I actually have the "default- character-set" set to "latin2" in the "[mysql]" section of my mysql.ini, but I guess you can have any other default character set defined as long as you will try to store characters that are NOT present in that particular codepage, your results will be the same as mine (ie. they will be replaced with question marks when stored into the database). If you want to reproduce the problem, it's obviously important NOT to have the default charset already set to UTF-8 in your MySQL config, as that will make the "SET NAMES" and "SET CHARACTER SET" commands - and the difference in their exhibited behaviour - practically ineffective. I actually have the "default- character-set" set to "latin2" in the "[mysql]" section of my mysql.ini, but I guess you can have any other default character set defined as long as you will try to store characters that are NOT present in that particular codepage, your results will be the same as mine (ie. they will be replaced with question marks when stored into the database). Nov 15, 2009 issue 208 (TDbConnection.Charset not working properly) reported by google...@pcforum.hu - What steps will reproduce the problem? 1. Create a a MySQL database 2. Create a table in the database with "DEFAULT CHARSET=utf8" and a "text" field 3. Create a Prado project to work with the MySQL database 4. Set <database ... Charset="utf8" /> in your application.xml 5. Try to store some text in the database table in the text field using UTF-8 encoding. Make sure the text includes some characters that aren't present in your current locale's character set 6. Try to retrieve the value of the just-stored text field and inspect it either using a simple echo, using MySQL Administrator or whatever you tool prefer. What is the expected output? What do you see instead? You would expect to get the UTF-8 encoded text back as you passed it to the database. However, that will not be the case, as the characters not present in your current locale's OEM character map will be replaced with "?" marks. Inspecting the database with MySQL Administrator or other 3rd party tools will reveal, that the problem doesn't lie with the data retrieval, as the actual data stored in the text field will already contain the question marks - so the problem already occurs at the time of the UPDATE/INSERT operation. The results observed in MySQL Administrator are proof, that this is not an issue with either the retrieval of the data or the printing of that (not in the Prado application code and not in the browser) - so please don't advise me to check those - as the data in the database is obviously in fact corrupt (ie. has some characters replaced with '?'). Also, if the data I'm storing in the database wouldn't be valid UTF-8 code for some reason, wouldn't be the proper encoding, etc., then the fix explained below wouldn't result in the ability to store the data successfully in the database (which is also observable in MySQL Admin, which - if I have the fix applied - will indeed display the correct Unicode content, will all characters appearing as they should). What version of the product are you using? On what operating system? Prado/3.1.6, MySQL/5.1.33-community, Windows 7 Please provide any additional information below. The problem can be fixed if you replace the 'SET CHARACTER SET' command used by TDbConnection::setConnectionCharset() with a 'SET NAMES' command. I'm not really sure why this is neccessary, as according to the MySQL docs 'SET CHARACTER SET' should be succifient. However, fact is, if you use 'SET NAMES' instead, everything falls into place, and the UTF-8 character data will be stored and retrieved properly in your Prado application. The drawback of the latter is however that it you obviously won't be able to use multiple (different) character sets with multiple database connections, as for some not-really-clear-to-me-yet reason 'SET NAMES' will affect/set the character sets used by all connections to the same server. (Maybe it has something to do with using persistent connections? Maybe it will only affect PDO connections? Don't know, haven't investigated this in detail.) What steps will reproduce the problem? 1. Create a a MySQL database 2. Create a table in the database with "DEFAULT CHARSET=utf8" and a "text" field 3. Create a Prado project to work with the MySQL database 4. Set <database ... Charset="utf8" /> in your application.xml 5. Try to store some text in the database table in the text field using UTF-8 encoding. Make sure the text includes some characters that aren't present in your current locale's character set 6. Try to retrieve the value of the just-stored text field and inspect it either using a simple echo, using MySQL Administrator or whatever you tool prefer. What is the expected output? What do you see instead? You would expect to get the UTF-8 encoded text back as you passed it to the database. However, that will not be the case, as the characters not present in your current locale's OEM character map will be replaced with "?" marks. Inspecting the database with MySQL Administrator or other 3rd party tools will reveal, that the problem doesn't lie with the data retrieval, as the actual data stored in the text field will already contain the question marks - so the problem already occurs at the time of the UPDATE/INSERT operation. The results observed in MySQL Administrator are proof, that this is not an issue with either the retrieval of the data or the printing of that (not in the Prado application code and not in the browser) - so please don't advise me to check those - as the data in the database is obviously in fact corrupt (ie. has some characters replaced with '?'). Also, if the data I'm storing in the database wouldn't be valid UTF-8 code for some reason, wouldn't be the proper encoding, etc., then the fix explained below wouldn't result in the ability to store the data successfully in the database (which is also observable in MySQL Admin, which - if I have the fix applied - will indeed display the correct Unicode content, will all characters appearing as they should). What version of the product are you using? On what operating system? Prado/3.1.6, MySQL/5.1.33-community, Windows 7 Please provide any additional information below. The problem can be fixed if you replace the 'SET CHARACTER SET' command used by TDbConnection::setConnectionCharset() with a 'SET NAMES' command. I'm not really sure why this is neccessary, as according to the MySQL docs 'SET CHARACTER SET' should be succifient. However, fact is, if you use 'SET NAMES' instead, everything falls into place, and the UTF-8 character data will be stored and retrieved properly in your Prado application. The drawback of the latter is however that it you obviously won't be able to use multiple (different) character sets with multiple database connections, as for some not-really-clear-to-me-yet reason 'SET NAMES' will affect/set the character sets used by all connections to the same server. (Maybe it has something to do with using persistent connections? Maybe it will only affect PDO connections? Don't know, haven't investigated this in detail.) Nov 15, 2009 issue 207 (Prado .chm help file not available anymore) reported by google...@pcforum.hu - The CHM version of Prado Manual (prado3_manual.chm) is not generated/available anymore. It's not present neither in the source distribution, nor in the documentation zip file. There's a directory in the trunk under "buildscripts/chmbuilder" which appears to be the builder for the CHM help file which, however, isn't included in the source distribution .zip file, and also doesn't seem to work properly anyway. Affected version is Prado/3.1.6, but I'm pretty sure other releases in this year didn't include the help file either. The last version of the manual I could locate on the web was for Prado/3.1.2, dated April 21st, 2008. The CHM version of Prado Manual (prado3_manual.chm) is not generated/available anymore. It's not present neither in the source distribution, nor in the documentation zip file. There's a directory in the trunk under "buildscripts/chmbuilder" which appears to be the builder for the CHM help file which, however, isn't included in the source distribution .zip file, and also doesn't seem to work properly anyway. Affected version is Prado/3.1.6, but I'm pretty sure other releases in this year didn't include the help file either. The last version of the manual I could locate on the web was for Prado/3.1.2, dated April 21st, 2008. Last 30 days Nov 14, 2009 prado-textmatebundle-r2734.zip (Prado Textmate Bundle) file uploaded by rojaro - Labels: OpSys-Windows OpSys-OSX Type-Archive prado textmate bundle Labels: OpSys-Windows OpSys-OSX Type-Archive prado textmate bundle Nov 08, 2009 issue 171 (<connection> tag in SqlMap config ignored in 3.1.5) Status changed by godzill...@gmx.net - Fixed - you are right this bug was introduce in 3.1.5 by solving Issue#68 . Sorry for the inconvenience - i was my fault. Status: Fixed Fixed - you are right this bug was introduce in 3.1.5 by solving Issue#68 . Sorry for the inconvenience - i was my fault. Status: Fixed Nov 08, 2009 r2745 (- Fixed Issue #171 - <connection> tag in SqlMap config ignor...) committed by godzill...@gmx.net - - Fixed Issue #171 - <connection> tag in SqlMap config ignored in 3.1.5 and above, introduced by solving Issue#68 - move logic to instantiate TSqlMapManager from "protected function createSqlMapGateway()" to "public function getSqlMapManager()" since it is useful if you dynamicly create mapped statements that should be cached - explicit return null in loadCachedSqlMapManager() - Fixed Issue #171 - <connection> tag in SqlMap config ignored in 3.1.5 and above, introduced by solving Issue#68 - move logic to instantiate TSqlMapManager from "protected function createSqlMapGateway()" to "public function getSqlMapManager()" since it is useful if you dynamicly create mapped statements that should be cached - explicit return null in loadCachedSqlMapManager() Nov 08, 2009 issue 171 (<connection> tag in SqlMap config ignored in 3.1.5) changed by godzill...@gmx.net - Seems to be a cache releated problem - it works as expected with EnableCache="false" Status: Accepted Owner: godzill...@gmx.net Labels: Component-Persistence Seems to be a cache releated problem - it works as expected with EnableCache="false" Status: Accepted Owner: godzill...@gmx.net Labels: Component-Persistence Nov 08, 2009 r2744 (Correct code formating of last commit) committed by godzill...@gmx.net - Correct code formating of last commit Correct code formating of last commit Nov 08, 2009 issue 151 (TTextBox fails to display inital blank line) changed by godzill...@gmx.net - Fixed - applied submitted patch Works in Firefox 3.5.5, IE 8, Safari 4, Chrome 3, Opera 9.6 on win based systems, but someone should check NIX and Mac because of different line break behavior. Status: Fixed Owner: godzill...@gmx.net Labels: Component-UI Fixed - applied submitted patch Works in Firefox 3.5.5, IE 8, Safari 4, Chrome 3, Opera 9.6 on win based systems, but someone should check NIX and Mac because of different line break behavior. Status: Fixed Owner: godzill...@gmx.net Labels: Component-UI Nov 08, 2009 r2743 (Fixed Issue #151 - TTextBox fails to display inital line bre...) committed by godzill...@gmx.net - Fixed Issue #151 - TTextBox fails to display inital line break Fixed Issue #151 - TTextBox fails to display inital line break Nov 08, 2009 issue 191 (Bad prasing of MySQL ENUM type column.) changed by godzill...@gmx.net - Fixed Status: Fixed Owner: godzill...@gmx.net Labels: Component-Persistence Fixed Status: Fixed Owner: godzill...@gmx.net Labels: Component-Persistence Nov 08, 2009 r2742 (Fixed Issue #191 - Bad parsing of MySQL ENUM type column) committed by godzill...@gmx.net - Fixed Issue #191 - Bad parsing of MySQL ENUM type column Fixed Issue #191 - Bad parsing of MySQL ENUM type column Nov 08, 2009 issue 188 (TDbCache->addValue() doesn't check if db connection is activ...) Status changed by godzill...@gmx.net - Fixed Status: Fixed Fixed Status: Fixed Nov 08, 2009 r2741 (Fixed Issue #188 - TDbCache doesn't check if db connection i...) committed by godzill...@gmx.net - Fixed Issue #188 - TDbCache doesn't check if db connection is active. Fixed Issue #188 - TDbCache doesn't check if db connection is active. Nov 08, 2009 issue 184 (THttpResponse doesn't support custom Content-Type headers) changed by godzill...@gmx.net - Fixed Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Fixed Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Nov 08, 2009 r2740 (Fix Issue #184 - THttpResponse doesn't support custom Conten...) committed by godzill...@gmx.net - Fix Issue #184 - THttpResponse doesn't support custom Content-Type headers, remove charset part of header if THttpResponse.Charset=false Fix Issue #184 - THttpResponse doesn't support custom Content-Type headers, remove charset part of header if THttpResponse.Charset=false Nov 08, 2009 issue 103 (TActiveCustomValidator CallBack problem) Status changed by godzill...@gmx.net - Can't reproduce issue, works as expected with PRADO 3.1.6 on WinXP Apache 2.2.x / nginx0.7.x in Firefox 3.0.11 & 3.5.5, IE 8, Safari 4, Chrome 3, Opera 9.6 Maybe the callback takes a little longer, you should verify this using Firebug!? Test: <com:TActiveTextBox ID="TextBox1" ValidationGroup="Group1" /> <com:TActiveButton Text="Submit" ValidationGroup="Group1" OnCallback="buttonClickedCallback" ActiveControl.EnableUpdate="true"/> <com:TActiveCustomValidator ValidationGroup="Group1" ControlToValidate="TextBox1" OnServerValidate="serverValidate" ActiveControl.EnableUpdate="true" Text="You must enter 'test'"/> public function serverValidate($sender, $param) { if($param -> getValue() !== 'test') $param -> setIsValid(false); } public function buttonClickedCallback($sender, $param) { if($this -> getIsValid()) $sender -> setText('Success'); } Status: Invalid Can't reproduce issue, works as expected with PRADO 3.1.6 on WinXP Apache 2.2.x / nginx0.7.x in Firefox 3.0.11 & 3.5.5, IE 8, Safari 4, Chrome 3, Opera 9.6 Maybe the callback takes a little longer, you should verify this using Firebug!? Test: <com:TActiveTextBox ID="TextBox1" ValidationGroup="Group1" /> <com:TActiveButton Text="Submit" ValidationGroup="Group1" OnCallback="buttonClickedCallback" ActiveControl.EnableUpdate="true"/> <com:TActiveCustomValidator ValidationGroup="Group1" ControlToValidate="TextBox1" OnServerValidate="serverValidate" ActiveControl.EnableUpdate="true" Text="You must enter 'test'"/> public function serverValidate($sender, $param) { if($param -> getValue() !== 'test') $param -> setIsValid(false); } public function buttonClickedCallback($sender, $param) { if($this -> getIsValid()) $sender -> setText('Success'); } Status: Invalid Nov 08, 2009 r2739 (Add property TValidationSummary.ScrollToSummary to server-si...) committed by godzill...@gmx.net - Add property TValidationSummary.ScrollToSummary to server-side control since property exists on client-side Add property TValidationSummary.ScrollToSummary to server-side control since property exists on client-side Nov 08, 2009 r2738 (Always render clientside counterparts of validation control ...) committed by godzill...@gmx.net - Always render clientside counterparts of validation control even if not enabled, but pass-through Enabled property, to allow Enabled/Disable of validator on callback. Always render clientside counterparts of validation control even if not enabled, but pass-through Enabled property, to allow Enabled/Disable of validator on callback. Nov 07, 2009 r2737 (Add property ClientScriptManagerClass to TPageService and re...) committed by godzill...@gmx.net - Add property ClientScriptManagerClass to TPageService and releated changes in TPage.getClientScript() to allow subclassing of TClientScriptManager Add property ClientScriptManagerClass to TPageService and releated changes in TPage.getClientScript() to allow subclassing of TClientScriptManager Nov 06, 2009 issue 206 (Unregister clientside validators from manager if container o...) commented on by godzill...@gmx.net - Nice idea - much more elegant and more performant on the server side - thanks :D Nice idea - much more elegant and more performant on the server side - thanks :D Nov 05, 2009 issue 206 (Unregister clientside validators from manager if container o...) commented on by google...@pcforum.hu - It would be probably easier to do the opposite, ie. ask the client side manager / registry itself - after an update - to validate each and every validator it has registered. This could be done by forcing each rendered and active validator to emit a <span> with a unique id in-place into the page code, and then asking the registry to look up the id's of each of it's registered validator in the DOM. If it can't find any elements with the specified id, it should dispose of the validator previously registered into it, as the validator is no more part of the page (or is disabled). Just an idea. It would be probably easier to do the opposite, ie. ask the client side manager / registry itself - after an update - to validate each and every validator it has registered. This could be done by forcing each rendered and active validator to emit a <span> with a unique id in-place into the page code, and then asking the registry to look up the id's of each of it's registered validator in the DOM. If it can't find any elements with the specified id, it should dispose of the validator previously registered into it, as the validator is no more part of the page (or is disabled). Just an idea. Nov 04, 2009 issue 206 (Unregister clientside validators from manager if container o...) reported by godzill...@gmx.net - What steps will reproduce the problem? - add TValidationSummary to TActivePanel - add TPanel to TActivePanel - add TTextBox & TRequiredFieldValidator to TPanel - add TActiveLinkButton with CausesValidation=true to TActivePanel - add TActiveLinkButton with CausesValidation=false to TActivePanel - click TActiveLinkButton with CausesValidation=true => TValidationSummary will be displayed - click TActiveLinkButton with CausesValidation=false and set TPanel.Visibile=false on callback What is the expected output? No validation message is displayed What do you see instead? Validation message is shown. Solution: Unregister clientside validators from manager if container of validator becomes invisible after callback What steps will reproduce the problem? - add TValidationSummary to TActivePanel - add TPanel to TActivePanel - add TTextBox & TRequiredFieldValidator to TPanel - add TActiveLinkButton with CausesValidation=true to TActivePanel - add TActiveLinkButton with CausesValidation=false to TActivePanel - click TActiveLinkButton with CausesValidation=true => TValidationSummary will be displayed - click TActiveLinkButton with CausesValidation=false and set TPanel.Visibile=false on callback What is the expected output? No validation message is displayed What do you see instead? Validation message is shown. Solution: Unregister clientside validators from manager if container of validator becomes invisible after callback Nov 04, 2009 r2736 (Minor corrections to avoid runtime notice with php 5.3, and ...) committed by Christophe.Boulain - Minor corrections to avoid runtime notice with php 5.3, and function rename in TDbConnection Minor corrections to avoid runtime notice with php 5.3, and function rename in TDbConnection Nov 02, 2009 r2735 (added missing package description in TActiveFileUpload ) committed by rojaro - added missing package description in TActiveFileUpload added missing package description in TActiveFileUpload Nov 01, 2009 r2734 (added a few more snippets to the textmate bundle ) committed by rojaro - added a few more snippets to the textmate bundle added a few more snippets to the textmate bundle Nov 01, 2009 r2733 (added missing package description ) committed by rojaro - added missing package description added missing package description Nov 01, 2009 r2732 (added a few new snippets to the textmate bundle ) committed by rojaro - added a few new snippets to the textmate bundle added a few new snippets to the textmate bundle Nov 01, 2009 r2731 (added old prado textmate bundle ) committed by rojaro - added old prado textmate bundle added old prado textmate bundle Nov 01, 2009 r2730 (TEnumerable can now be iterated as suggested by FragMaster B...) committed by rojaro - TEnumerable can now be iterated as suggested by FragMaster B TEnumerable can now be iterated as suggested by FragMaster B Nov 01, 2009 r2729 (Added ability to set width and height for images in both THy...) committed by rojaro - Added ability to set width and height for images in both THyperLink and THyperLinkColumn (plus the imageurl for the latter) as suggested by junkee in http://www.pradosoft.com/forum/index.php?topic=8745.0 Added ability to set width and height for images in both THyperLink and THyperLinkColumn (plus the imageurl for the latter) as suggested by junkee in http://www.pradosoft.com/forum/index.php?topic=8745.0 Nov 01, 2009 r2728 (merged fix for proper errorhandling when the size of the upl...) committed by rojaro - merged fix for proper errorhandling when the size of the uploaded file exceeds the limit see http://www.pradosoft.com/forum/index.php?topic=11850.0 merged fix for proper errorhandling when the size of the uploaded file exceeds the limit see http://www.pradosoft.com/forum/index.php?topic=11850.0 Nov 01, 2009 r2727 (merged fix for asynchronous callback requests from http://ww...) committed by rojaro - merged fix for asynchronous callback requests from http://www.pradosoft.com/forum/index.php?topic=12179.0 merged fix for asynchronous callback requests from http://www.pradosoft.com/forum/index.php?topic=12179.0 Nov 01, 2009 r2726 (merged quotestring utf8 patch ... see http://www.pradosoft.c...) committed by rojaro - merged quotestring utf8 patch ... see http://www.pradosoft.com/forum/index.php?topic=11700.msg51530;topicseen#msg51530 merged quotestring utf8 patch ... see http://www.pradosoft.com/forum/index.php?topic=11700.msg51530;topicseen#msg51530 Nov 01, 2009 r2725 (merged active record default value bug fix which got lost wh...) committed by rojaro - merged active record default value bug fix which got lost when moving from trac to googlecode - see http://www.pradosoft.com/forum/index.php?topic=10603.0 merged active record default value bug fix which got lost when moving from trac to googlecode - see http://www.pradosoft.com/forum/index.php?topic=10603.0 Nov 01, 2009 r2724 (added Dreamweaver extension so it doesnt get "lost" again ) committed by rojaro - added Dreamweaver extension so it doesnt get "lost" again added Dreamweaver extension so it doesnt get "lost" again Nov 01, 2009 r2723 (fixed error handler to detect changes in the error reporting...) committed by rojaro - fixed error handler to detect changes in the error reporting level after initialisation as suggested by acron in http://www.pradosoft.com/forum/index.php?topic=12226.0 fixed error handler to detect changes in the error reporting level after initialisation as suggested by acron in http://www.pradosoft.com/forum/index.php?topic=12226.0 Earlier this year Oct 19, 2009 issue 205 (Feature Request: Add support for fully qualified URL-matchin...) commented on by google...@pcforum.hu - I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. Oct 19, 2009 issue 205 (Feature Request: Add support for fully qualified URL-matchin...) commented on by google...@pcforum.hu - I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. Oct 19, 2009 issue 205 (Feature Request: Add support for fully qualified URL-matchin...) commented on by google...@pcforum.hu - I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. Oct 19, 2009 issue 205 (Feature Request: Add support for fully qualified URL-matchin...) commented on by google...@pcforum.hu - I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. I've implemented this feature in the attached file (source based on stock 3.1.6 sources). TUrlMappingPattern (and thus the <url> tags in the mapping config) now have a new property named 'UrlMatchMode', which defaults to 'PathInfo', but if set to 'Full', it will match the Pattern property against the pathinfo+querystring, parts instead of just the pathinfo part itself of the request. It will also escape the "?" character for the regular expr. matching in the Pattern if there's one. I've tested and need this only in EnableCustomUrl=false mode (eg. only to divert calls to pages based on the params, not construct any urls using those), so it will have to be tested with EnableCustomUrl=true yet, whether it works as expected. Oct 19, 2009 issue 205 (Feature Request: Add support for fully qualified URL-matchin...) reported by google...@pcforum.hu - TUrlMapping (well, actually TUrlMappingPattern) currently only supports mapping based on the "pathinfo" part of the url, and provides no way to provide any mapping which also considers any parameters passed to the script in the "querystring" part of the url. I however fail to see why this limitation is there. Without this, one must fall back to use .htaccess rewrite techniques, contradicting the primary purpose of Prado's url mapping (which in my understanding is allowing developers to avoid those url rewrites from config, and moving that logic integral to the application), in cases where for ex. you want to have calls diverted to different pages based on specific query parameter values in the url. (For ex. you might have moved the functionality once implemented in the same page now apart, to two more pages, without invalidating already created and stored urls in the application, in search engines, etc.) This limitation, however, could be easily overcomed would TUrlMappingPattern provide a way to use the result of $request- >getRequestUri() instead of $request->getPathInfo(). Therefore I propose to add a new property to the latter class, which would enable developers to make use of that extra part of the url, too, in match-checks (againt the pathinfo+querystring part of the url), while also preserving backwards compatibility (matching against only the path info). TUrlMapping (well, actually TUrlMappingPattern) currently only supports mapping based on the "pathinfo" part of the url, and provides no way to provide any mapping which also considers any parameters passed to the script in the "querystring" part of the url. I however fail to see why this limitation is there. Without this, one must fall back to use .htaccess rewrite techniques, contradicting the primary purpose of Prado's url mapping (which in my understanding is allowing developers to avoid those url rewrites from config, and moving that logic integral to the application), in cases where for ex. you want to have calls diverted to different pages based on specific query parameter values in the url. (For ex. you might have moved the functionality once implemented in the same page now apart, to two more pages, without invalidating already created and stored urls in the application, in search engines, etc.) This limitation, however, could be easily overcomed would TUrlMappingPattern provide a way to use the result of $request- >getRequestUri() instead of $request->getPathInfo(). Therefore I propose to add a new property to the latter class, which would enable developers to make use of that extra part of the url, too, in match-checks (againt the pathinfo+querystring part of the url), while also preserving backwards compatibility (matching against only the path info). Oct 16, 2009 issue 204 (Pradosoft.com domain expired) Status changed by rojaro - Seems that this was a temporary problem at godaddy.com. Status: Invalid Seems that this was a temporary problem at godaddy.com. Status: Invalid Oct 16, 2009 issue 204 (Pradosoft.com domain expired) reported by ctrlaltca - What steps will reproduce the problem? 1. Point your browser to the official prado website What is the expected output? What do you see instead? Expected output: prado website; instead, i see a domain register webpage. What version of the product are you using? On what operating system? --- Please provide any additional information below. Domain Name: PRADOSOFT.COM Registrar: GODADDY.COM, INC. Whois Server: whois.godaddy.com Referral URL: http://registrar.godaddy.com Name Server: NS29.DOMAINCONTROL.COM Name Server: NS30.DOMAINCONTROL.COM Status: clientDeleteProhibited Status: clientRenewProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Updated Date: 16-oct-2009 Creation Date: 05-feb-2005 Expiration Date: 05-feb-2011 What steps will reproduce the problem? 1. Point your browser to the official prado website What is the expected output? What do you see instead? Expected output: prado website; instead, i see a domain register webpage. What version of the product are you using? On what operating system? --- Please provide any additional information below. Domain Name: PRADOSOFT.COM Registrar: GODADDY.COM, INC. Whois Server: whois.godaddy.com Referral URL: http://registrar.godaddy.com Name Server: NS29.DOMAINCONTROL.COM Name Server: NS30.DOMAINCONTROL.COM Status: clientDeleteProhibited Status: clientRenewProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Updated Date: 16-oct-2009 Creation Date: 05-feb-2005 Expiration Date: 05-feb-2011 Oct 14, 2009 issue 203 (->CallbackClient->click doesn't work in IE7 and IE8) reported by mcsakoff - Test.page: ... <com:TActiveButton ID="activeButton" Text="Fire Callback" OnClick="onActiveButtonClicked" /> <com:TButton ID="passiveButton" Text="Fire Postback" OnClick="onButtonClicked" /> ... Test.php: ... public function onActiveButtonClicked( $sender, $param ) { print "onActiveButtonClicked"; $this->CallbackClient->click( $this->passiveButton ); } public function onButtonClicked( $sender, $param ) { print "onButtonClicked"; } ... 2. Click "Fire Callback" button. The page should be reloaded and "onButtonClicked" displayed on it. That works fine in FF and Opera but not in IE7 and IE8. On IE it prints to JavaScript console: HTTP 200 with response : onCallbackClicked Actions : {"Prado.Element.click":["ctl0_ctl0_body_main_passiveButton"]} but the button is not actually clicked. I found two problems here. IE doesn't like when client side function is called "click". I've fixed that renaming function to something like "click_on": TCallbackClientScript.php,113: ... /** * Client script to click on an element. <b>This client-side function * is unpredictable.</b> * @param TControl control element or element id / public function click($control) { $this->callClientFunction('Prado.Element.click_on', $control); } ... scriptaculous-adapter.js,251: ... /* * Trigger a click event on a DOM element. * * @function ? * @param {string} element - Element id / click_on : function(element) { var el = $(element); if(el) Event.fireEvent(el,'click'); }, ... Second problem is that as promised the client side function is unpredictable. So, I've just changed Event.fireEvent(el,'click') to simple el.click(); Of course that works for buttons only, but at least that works! click_on : function(element) { var el = $(element); el.click(); }, --- Prado 3.1.6, Gentoo x86. Test.page: ... <com:TActiveButton ID="activeButton" Text="Fire Callback" OnClick="onActiveButtonClicked" /> <com:TButton ID="passiveButton" Text="Fire Postback" OnClick="onButtonClicked" /> ... Test.php: ... public function onActiveButtonClicked( $sender, $param ) { print "onActiveButtonClicked"; $this->CallbackClient->click( $this->passiveButton ); } public function onButtonClicked( $sender, $param ) { print "onButtonClicked"; } ... 2. Click "Fire Callback" button. The page should be reloaded and "onButtonClicked" displayed on it. That works fine in FF and Opera but not in IE7 and IE8. On IE it prints to JavaScript console: HTTP 200 with response : onCallbackClicked Actions : {"Prado.Element.click":["ctl0_ctl0_body_main_passiveButton"]} but the button is not actually clicked. I found two problems here. IE doesn't like when client side function is called "click". I've fixed that renaming function to something like "click_on": TCallbackClientScript.php,113: ... /* * Client script to click on an element. <b>This client-side function * is unpredictable.</b> * @param TControl control element or element id / public function click($control) { $this->callClientFunction('Prado.Element.click_on', $control); } ... scriptaculous-adapter.js,251: ... /* * Trigger a click event on a DOM element. * * @function ? * @param {string} element - Element id */ click_on : function(element) { var el = $(element); if(el) Event.fireEvent(el,'click'); }, ... Second problem is that as promised the client side function is unpredictable. So, I've just changed Event.fireEvent(el,'click') to simple el.click(); Of course that works for buttons only, but at least that works! click_on : function(element) { var el = $(element); el.click(); }, --- Prado 3.1.6, Gentoo x86. Oct 14, 2009 r2722 (added TActiveMultiView ) committed by rojaro - added TActiveMultiView added TActiveMultiView Oct 12, 2009 issue 202 (cache got error after i delete the runtime ) reported by setiawan.ricky - What steps will reproduce the problem? 1. I Add <modules> <module id="cache" class="System.Caching.TSqliteCache" /> </modules> in application.xml 2. i delete the runtime What is the expected output? What do you see instead? TConfigurationException Description TContent 'LOGO' does not have a matching TContentPlaceHolder. Source File C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php (5646) 5635: } 5636: public function injectContent($id,$content) 5637: { 5638: if(isset($this->_placeholders[$id])) 5639: { 5640: $placeholder=$this->_placeholders[$id]; 5641: $controls=$placeholder->getParent()->getControls(); 5642: $loc=$controls->remove($placeholder); 5643: $controls->insertAt($loc,$content); 5644: } 5645: else 5646: throw new TConfigurationException('templatecontrol_placeholder_inexistent',$id); 5647: } 5648: protected function initRecursive($namingContainer=null) 5649: { 5650: $this->ensureChildControls(); 5651: if($this->_masterClass!=='') 5652: { 5653: $master=Prado::createComponent($this->_masterClass); 5654: if(!($master instanceof TTemplateControl)) 5655: throw new TInvalidDataValueException('templatecontrol_mastercontrol_invalid'); 5656: $this->_master=$master; 5657: $this->getControls()->clear(); 5658: $this->getControls()->add($master); Stack Trace #0 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(5661): TTemplateControl->injectContent('LOGO', Object(TContent)) #1 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(6199): TTemplateControl->initRecursive() #2 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(6194): TPage->processNormalRequest(Object(THtmlWriter)) #3 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8333): TPage->run(Object(THtmlWriter)) #4 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8299): TPageService->runPage(Object(m_ProductType), Array) #5 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(9285): TPageService->run() #6 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8887): TApplication->runService() #7 C:\MyFolder\XAMPP\htdocs\aa\index.php(23): TApplication->run() #8 {main} What version of the product are you using? On what operating system? 3.16 Please provide any additional information below. My Name is Ricky I still nubie in prado , i want to make my project application performance more smooth. Please help me setiawan.ricky@gmail.com What steps will reproduce the problem? 1. I Add <modules> <module id="cache" class="System.Caching.TSqliteCache" /> </modules> in application.xml 2. i delete the runtime What is the expected output? What do you see instead? TConfigurationException Description TContent 'LOGO' does not have a matching TContentPlaceHolder. Source File C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php (5646) 5635: } 5636: public function injectContent($id,$content) 5637: { 5638: if(isset($this->_placeholders[$id])) 5639: { 5640: $placeholder=$this->_placeholders[$id]; 5641: $controls=$placeholder->getParent()->getControls(); 5642: $loc=$controls->remove($placeholder); 5643: $controls->insertAt($loc,$content); 5644: } 5645: else 5646: throw new TConfigurationException('templatecontrol_placeholder_inexistent',$id); 5647: } 5648: protected function initRecursive($namingContainer=null) 5649: { 5650: $this->ensureChildControls(); 5651: if($this->_masterClass!=='') 5652: { 5653: $master=Prado::createComponent($this->_masterClass); 5654: if(!($master instanceof TTemplateControl)) 5655: throw new TInvalidDataValueException('templatecontrol_mastercontrol_invalid'); 5656: $this->_master=$master; 5657: $this->getControls()->clear(); 5658: $this->getControls()->add($master); Stack Trace #0 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(5661): TTemplateControl->injectContent('LOGO', Object(TContent)) #1 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(6199): TTemplateControl->initRecursive() #2 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(6194): TPage->processNormalRequest(Object(THtmlWriter)) #3 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8333): TPage->run(Object(THtmlWriter)) #4 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8299): TPageService->runPage(Object(m_ProductType), Array) #5 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(9285): TPageService->run() #6 C:\MyFolder\XAMPP\htdocs\aa\protected\AppCode\lib\framework\pradolite.php(8887): TApplication->runService() #7 C:\MyFolder\XAMPP\htdocs\aa\index.php(23): TApplication->run() #8 {main} What version of the product are you using? On what operating system? 3.16 Please provide any additional information below. My Name is Ricky I still nubie in prado , i want to make my project application performance more smooth. Please help me setiawan.ricky@gmail.com Oct 07, 2009 r2721 (Add TActiveTableCell & TActiveTableRow) committed by Christophe.Boulain - Add TActiveTableCell & TActiveTableRow Add TActiveTableCell & TActiveTableRow Oct 05, 2009 issue 187 (Documentation Errors) Labels changed by Christophe.Boulain - 1. The both page, even if almost identical, are different. The first one talks about Content Tag (tag that can be used in template), the second one talks about Properties tag (ie, tag that can be used in component property). 2. The sqlmap tutorial shares the same theme than the quickstart tutorial, and, because the title is an image, and not a text, it shows the image from quickstart. We may fix this later, if we have some time, but it's really not the priority :) I remove the milestone information, but keep this issue opened. Labels: Type-Task Priority-Low −Type-Defect −Priority-Medium −Milestone-3.1.7 1. The both page, even if almost identical, are different. The first one talks about Content Tag (tag that can be used in template), the second one talks about Properties tag (ie, tag that can be used in component property). 2. The sqlmap tutorial shares the same theme than the quickstart tutorial, and, because the title is an image, and not a text, it shows the image from quickstart. We may fix this later, if we have some time, but it's really not the priority :) I remove the milestone information, but keep this issue opened. Labels: Type-Task Priority-Low −Type-Defect −Priority-Medium −Milestone-3.1.7 Oct 05, 2009 issue 193 (Problem with some dates in TDatePicker) Status changed by Christophe.Boulain - Can't reproduce. See screenshot of TDatePicker in QST. Status: Invalid Can't reproduce. See screenshot of TDatePicker in QST. Status: Invalid

issue 208 (TDbConnection.Charset not working properly) reported by google...@pcforum.hu - What steps will reproduce the problem? 1. Create a a MySQL database 2. Create a table in the database with "DEFAULT CHARSET=utf8" and a "text" field 3. Create a Prado project to work with the MySQL database 4. Set <database ... Charset="utf8" /> in your application.xml 5. Try to store some text in the database table in the text field using UTF-8 encoding. Make sure the text includes some characters that aren't present in your current locale's character set 6. Try to retrieve the value of the just-stored text field and inspect it either using a simple echo, using MySQL Administrator or whatever you tool prefer. What is the expected output? What do you see instead? You would expect to get the UTF-8 encoded text back as you passed it to the database. However, that will not be the case, as the characters not present in your current locale's OEM character map will be replaced with "?" marks. Inspecting the database with MySQL Administrator or other 3rd party tools will reveal, that the problem doesn't lie with the data retrieval, as the actual data stored in the text field will already contain the question marks - so the problem already occurs at the time of the UPDATE/INSERT operation. The results observed in MySQL Administrator are proof, that this is not an issue with either the retrieval of the data or the printing of that (not in the Prado application code and not in the browser) - so please don't advise me to check those - as the data in the database is obviously in fact corrupt (ie. has some characters replaced with '?'). Also, if the data I'm storing in the database wouldn't be valid UTF-8 code for some reason, wouldn't be the proper encoding, etc., then the fix explained below wouldn't result in the ability to store the data successfully in the database (which is also observable in MySQL Admin, which - if I have the fix applied - will indeed display the correct Unicode content, will all characters appearing as they should). What version of the product are you using? On what operating system? Prado/3.1.6, MySQL/5.1.33-community, Windows 7 Please provide any additional information below. The problem can be fixed if you replace the 'SET CHARACTER SET' command used by TDbConnection::setConnectionCharset() with a 'SET NAMES' command. I'm not really sure why this is neccessary, as according to the MySQL docs 'SET CHARACTER SET' should be succifient. However, fact is, if you use 'SET NAMES' instead, everything falls into place, and the UTF-8 character data will be stored and retrieved properly in your Prado application. The drawback of the latter is however that it you obviously won't be able to use multiple (different) character sets with multiple database connections, as for some not-really-clear-to-me-yet reason 'SET NAMES' will affect/set the character sets used by all connections to the same server. (Maybe it has something to do with using persistent connections? Maybe it will only affect PDO connections? Don't know, haven't investigated this in detail.)

What steps will reproduce the problem? 1. Create a a MySQL database 2. Create a table in the database with "DEFAULT CHARSET=utf8" and a "text" field 3. Create a Prado project to work with the MySQL database 4. Set <database ... Charset="utf8" /> in your application.xml 5. Try to store some text in the database table in the text field using UTF-8 encoding. Make sure the text includes some characters that aren't present in your current locale's character set 6. Try to retrieve the value of the just-stored text field and inspect it either using a simple echo, using MySQL Administrator or whatever you tool prefer. What is the expected output? What do you see instead? You would expect to get the UTF-8 encoded text back as you passed it to the database. However, that will not be the case, as the characters not present in your current locale's OEM character map will be replaced with "?" marks. Inspecting the database with MySQL Administrator or other 3rd party tools will reveal, that the problem doesn't lie with the data retrieval, as the actual data stored in the text field will already contain the question marks - so the problem already occurs at the time of the UPDATE/INSERT operation. The results observed in MySQL Administrator are proof, that this is not an issue with either the retrieval of the data or the printing of that (not in the Prado application code and not in the browser) - so please don't advise me to check those - as the data in the database is obviously in fact corrupt (ie. has some characters replaced with '?'). Also, if the data I'm storing in the database wouldn't be valid UTF-8 code for some reason, wouldn't be the proper encoding, etc., then the fix explained below wouldn't result in the ability to store the data successfully in the database (which is also observable in MySQL Admin, which - if I have the fix applied - will indeed display the correct Unicode content, will all characters appearing as they should). What version of the product are you using? On what operating system? Prado/3.1.6, MySQL/5.1.33-community, Windows 7 Please provide any additional information below. The problem can be fixed if you replace the 'SET CHARACTER SET' command used by TDbConnection::setConnectionCharset() with a 'SET NAMES' command. I'm not really sure why this is neccessary, as according to the MySQL docs 'SET CHARACTER SET' should be succifient. However, fact is, if you use 'SET NAMES' instead, everything falls into place, and the UTF-8 character data will be stored and retrieved properly in your Prado application. The drawback of the latter is however that it you obviously won't be able to use multiple (different) character sets with multiple database connections, as for some not-really-clear-to-me-yet reason 'SET NAMES' will affect/set the character sets used by all connections to the same server. (Maybe it has something to do with using persistent connections? Maybe it will only affect PDO connections? Don't know, haven't investigated this in detail.)

Last 7 days

Last 30 days

Earlier this year