prado3 - Google Code

Last 7 days Jul 02, 2009 issue 182 (The source language for Globalization defaults to en and the...) reported by piotrowski.mb - There should be a way to specify what is the source language of application. What steps will reproduce the problem? 1.Create an application with globalization module set up and at least one TTranslate component or Prado::localize() call. 2.Set globalization.Culture, globalization.DefaultCulture to non-english in module config and marker to not "". 3.Run the application with culture set to the same as in globalization module. The text shouldn't be translated, but it is surrounded with marker. What version of the product are you using? On what operating system? Please provide any additional information below. There should be a way to specify what is the source language of application. What steps will reproduce the problem? 1.Create an application with globalization module set up and at least one TTranslate component or Prado::localize() call. 2.Set globalization.Culture, globalization.DefaultCulture to non-english in module config and marker to not "". 3.Run the application with culture set to the same as in globalization module. The text shouldn't be translated, but it is surrounded with marker. What version of the product are you using? On what operating system? Please provide any additional information below. Jun 30, 2009 issue 115 (enhancement: registry for Prado generated clientside counter...) changed by Christophe.Boulain - Status: Accepted Owner: godzill...@gmx.net Labels: Priority-Low Milestone-3.1.6 −Priority-Medium −Milestone-3.1.5 Status: Accepted Owner: godzill...@gmx.net Labels: Priority-Low Milestone-3.1.6 −Priority-Medium −Milestone-3.1.5 Jun 30, 2009 issue 115 (enhancement: registry for Prado generated clientside counter...) commented on by piotrowski.mb - The registry is great. The patch however doesn't cover all controls - for example the TAutoComplete can't be found in the registry. The registry is great. The patch however doesn't cover all controls - for example the TAutoComplete can't be found in the registry. Jun 29, 2009 issue 172 (TDbCache fails to recognize need to create cache table) Status changed by godzill...@gmx.net - Fixed in 3.1 branch. Status: Fixed Fixed in 3.1 branch. Status: Fixed Jun 29, 2009 r2684 (Fixed Issue#172 - TDbCache fails to recognize need to re-cre...) committed by godzill...@gmx.net - Fixed Issue#172 - TDbCache fails to recognize need to re-create cache table Fixed Issue#172 - TDbCache fails to recognize need to re-create cache table Jun 28, 2009 issue 54 (ActiveRecord, MySQL - Error in foreign key check on multiple...) commented on by kankan - What is schema part in the table name declaration? I am trying to implement the blog tutorial using MySql. I am at point day 4 :: Creating List Posts. But I get the error "Unable to find foreign key relationships in table '`posts`' that corresponds to table '`users`'." I removed the line "CONSTRAINT fk_author REFERENCES users(username)" from the supplied SqlLite Schema as mysql does not understand that part. What is schema part in the table name declaration? I am trying to implement the blog tutorial using MySql. I am at point day 4 :: Creating List Posts. But I get the error "Unable to find foreign key relationships in table '`posts`' that corresponds to table '`users`'." I removed the line "CONSTRAINT fk_author REFERENCES users(username)" from the supplied SqlLite Schema as mysql does not understand that part. Jun 28, 2009 r2683 (Performance optimization in PradoBase::createComponent()) committed by godzill...@gmx.net - Performance optimization in PradoBase::createComponent() Performance optimization in PradoBase::createComponent() Jun 27, 2009 issue 177 (THttpResponse::setStatusCode() has no effect) commented on by google...@pcforum.hu - Thanks for the reply. I indeed have tried your first solution - but it didn't work for me. Now I realize it just appeared not to work, because I tested it with IE, and for some weird reason MS modified IE8 in a way, that if it gets a HTTP error from the server (or can't even contant the server in the first place) for a page that it's already displaying, and you just pressed page refresh (F5) for, then it will keep displaying the old page, instead of showing the well known error-page. I'm not sure whether this is by design or just a bug, but IE8 definitively works that way - I've stumbled accross that behaviour multiple times. Anyway, I think the Prado documentation should be modified or extended to contain more information about how to use THTTPResponse::setStatusCode() (for ex. a Wiki entry could be created by pasting your reply :), as the need of returning a custom error is a fairly common situation in web applications. However, currently the documentation only references setStatusCode() at two places: 1. in the topic dicussing the THTTPResponse class and its methods, but it doesn't state anything about it there beyond the obvious, and 2. in the Wiki entry about database based authentication, but there you can only see the ::completeRequest() call right after ::setStatusCode() - no THttpResponse::flush() anywhere, so somebody looking how to return a custom code will be only foiled by that, but he will be unable to find any information on how to do that properly in the documentation. Thanks for the reply. I indeed have tried your first solution - but it didn't work for me. Now I realize it just appeared not to work, because I tested it with IE, and for some weird reason MS modified IE8 in a way, that if it gets a HTTP error from the server (or can't even contant the server in the first place) for a page that it's already displaying, and you just pressed page refresh (F5) for, then it will keep displaying the old page, instead of showing the well known error-page. I'm not sure whether this is by design or just a bug, but IE8 definitively works that way - I've stumbled accross that behaviour multiple times. Anyway, I think the Prado documentation should be modified or extended to contain more information about how to use THTTPResponse::setStatusCode() (for ex. a Wiki entry could be created by pasting your reply :), as the need of returning a custom error is a fairly common situation in web applications. However, currently the documentation only references setStatusCode() at two places: 1. in the topic dicussing the THTTPResponse class and its methods, but it doesn't state anything about it there beyond the obvious, and 2. in the Wiki entry about database based authentication, but there you can only see the ::completeRequest() call right after ::setStatusCode() - no THttpResponse::flush() anywhere, so somebody looking how to return a custom code will be only foiled by that, but he will be unable to find any information on how to do that properly in the documentation. Last 30 days Jun 27, 2009 issue 176 (Feature Request: Provide a way to supply download filename t...) changed by godzill...@gmx.net - Fixed in 3.1 branch. I've add 3 additional parameters to take more influence on behavior: boolean $forceDownload: force download of file, even if browser able to display inline. Defaults to 'true'. string $fileNameClient: force a specific file name on client side. Defaults to 'null' means auto-detect. integer fileSize: size of file or content in bytes if already known. Defaults to 'null' means auto-detect. Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Fixed in 3.1 branch. I've add 3 additional parameters to take more influence on behavior: boolean $forceDownload: force download of file, even if browser able to display inline. Defaults to 'true'. string $fileNameClient: force a specific file name on client side. Defaults to 'null' means auto-detect. integer fileSize: size of file or content in bytes if already known. Defaults to 'null' means auto-detect. Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Jun 27, 2009 r2682 (Fixed Issue#176 - THttpResponse::writeFile() add additional ...) committed by godzill...@gmx.net - Fixed Issue#176 - THttpResponse::writeFile() add additional parameters to take more influence on behavior (forceDownload, clientFileName, fileSize), add png to defaultMimeTypes Fixed Issue#176 - THttpResponse::writeFile() add additional parameters to take more influence on behavior (forceDownload, clientFileName, fileSize), add png to defaultMimeTypes Jun 27, 2009 issue 163 (sqlmap: two select on two map files can't have same id) Status changed by godzill...@gmx.net - Your describe behavior is no bug since id's of mappings are unique per TSqlMapConfig. Different files within same TSqlMapConfig just allow you to structure your mappings. if like to have same id in a diffent file you have to instantiate another TSqlMapConfig. Status: Invalid Your describe behavior is no bug since id's of mappings are unique per TSqlMapConfig. Different files within same TSqlMapConfig just allow you to structure your mappings. if like to have same id in a diffent file you have to instantiate another TSqlMapConfig. Status: Invalid Jun 27, 2009 r2681 (TCallbackErrorHandler::displayException() force HTTP status ...) committed by godzill...@gmx.net - TCallbackErrorHandler::displayException() force HTTP status "500 Internal Server Error" to ensure TCallbackOptions.ClientSide.OnFailure is raised TCallbackErrorHandler::displayException() force HTTP status "500 Internal Server Error" to ensure TCallbackOptions.ClientSide.OnFailure is raised Jun 26, 2009 issue 177 (THttpResponse::setStatusCode() has no effect) Status changed by godzill...@gmx.net - All steps of application lifecycle invoked in a loop - the only exception is the last step "onEndRequest" which invoked manualy to ensure logging functionality. Your describe behavior is no bug - by invoking "completeRequest" you terminate processing application lifecycles. Since "flushOutput" (send header & content) is the penultimate step of application lifecycles (last step in the loop) it is impossible to consider your http statuscode. Solution I: ---------------------------------------------- $this->getResponse()->setStatusCode(404,'Document not found'); $this->getResponse()->flush(); echo 'Your "Not Found" Message goes here'; $this->getApplication()->completeRequest(); Solution II: ---------------------------------------------- throw new THttpException(404, 'Your "Not Found" Message goes here'); Solution II offers some opportunities to to customize error page: 1. Customize exceptions templates ---------------------------------------------- copy templates located in: "${pradodir}/framework/Exceptions/templates" into: "${yourapplicationdir}/protected/ErrorTemplates" modify your application config: <module id="error" class="System.Exceptions.TErrorHandler" ErrorTemplatePath="Application.ErrorTemplates"/> now you can customize your error pages 2. Customize ErrorHandler ---------------------------------------------- class YourApplicationErrorHandler extends TErrorHandler { protected function displayException($exception) { if( <Your custom exception handling condition> ) { <Your custom exception handling rendering> } else parent::displayException($exception); } Status: Invalid All steps of application lifecycle invoked in a loop - the only exception is the last step "onEndRequest" which invoked manualy to ensure logging functionality. Your describe behavior is no bug - by invoking "completeRequest" you terminate processing application lifecycles. Since "flushOutput" (send header & content) is the penultimate step of application lifecycles (last step in the loop) it is impossible to consider your http statuscode. Solution I: ---------------------------------------------- $this->getResponse()->setStatusCode(404,'Document not found'); $this->getResponse()->flush(); echo 'Your "Not Found" Message goes here'; $this->getApplication()->completeRequest(); Solution II: ---------------------------------------------- throw new THttpException(404, 'Your "Not Found" Message goes here'); Solution II offers some opportunities to to customize error page: 1. Customize exceptions templates ---------------------------------------------- copy templates located in: "${pradodir}/framework/Exceptions/templates" into: "${yourapplicationdir}/protected/ErrorTemplates" modify your application config: <module id="error" class="System.Exceptions.TErrorHandler" ErrorTemplatePath="Application.ErrorTemplates"/> now you can customize your error pages 2. Customize ErrorHandler ---------------------------------------------- class YourApplicationErrorHandler extends TErrorHandler { protected function displayException($exception) { if( <Your custom exception handling condition> ) { <Your custom exception handling rendering> } else parent::displayException($exception); } Status: Invalid Jun 25, 2009 r2680 (- added missing namespacepath elements for schemas ) committed by rojaro - - added missing namespacepath elements for schemas - added missing namespacepath elements for schemas Jun 20, 2009 issue 181 (Prado client-side flawed - aka Multiple client-side (JS) obj...) commented on by google...@pcforum.hu - OK I just got a simpler idead to fix the issue. That is: there should be a client- side registry these JavaScript-supported controls, and the JS-objects themselves should be modified so they register themselves and the events they want to listen to in that registry. Now if there's a registration for the same control, the registry should first dispose of the old object for that control - if there's any already - and register the new object as the handler for the control and for the future. It is important tho that when deregistering, the object should release all event handlers and such too it hooked when it was created. It is also important that all controls preserve their state information in the DOM (instead of in the JavaScript object) or that when a replacement in the registry occours, all state fields of the previous object get copied to the new one (they should have a method for this in that case), so that the control's state information doesn't get lost. I'm also thinking about whether this issue with multiple instances does affect other controls too, which render "Event.observe()" snippets in their OnPreRender() methods using registerEndScript(). That might lead to multiple events (event handlers) fired for a single event on a single control too, after one or more callbacks have been executed on the page, but I will still have to check that. Anyway, it would be good to hear something from the Prado core developers about this issue, as it is a really serious design flaw I think, which could affect practically all Prado applications and lead to very weird and seemingly untraceable bugs, therefore should be fixed ASAP. OK I just got a simpler idead to fix the issue. That is: there should be a client- side registry these JavaScript-supported controls, and the JS-objects themselves should be modified so they register themselves and the events they want to listen to in that registry. Now if there's a registration for the same control, the registry should first dispose of the old object for that control - if there's any already - and register the new object as the handler for the control and for the future. It is important tho that when deregistering, the object should release all event handlers and such too it hooked when it was created. It is also important that all controls preserve their state information in the DOM (instead of in the JavaScript object) or that when a replacement in the registry occours, all state fields of the previous object get copied to the new one (they should have a method for this in that case), so that the control's state information doesn't get lost. I'm also thinking about whether this issue with multiple instances does affect other controls too, which render "Event.observe()" snippets in their OnPreRender() methods using registerEndScript(). That might lead to multiple events (event handlers) fired for a single event on a single control too, after one or more callbacks have been executed on the page, but I will still have to check that. Anyway, it would be good to hear something from the Prado core developers about this issue, as it is a really serious design flaw I think, which could affect practically all Prado applications and lead to very weird and seemingly untraceable bugs, therefore should be fixed ASAP. Jun 19, 2009 issue 181 (Prado client-side flawed - aka Multiple client-side (JS) obj...) commented on by google...@pcforum.hu - Test suite attached. Test suite attached. Jun 19, 2009 issue 181 (Prado client-side flawed - aka Multiple client-side (JS) obj...) reported by google...@pcforum.hu - The current implementation of several JS-supported non-active controls and/or of TClientScriptManager::registerPostBackControl() interferes with the active control / callback mechanism in Prado, as it doesn't care about the type of the actual page cycle and the state of the control. The problem is that nor registerPostBackControl() neither its callers care about whether the actual page-cycle is a full-page reload or just a callback, and they (actually registerPostBackControl()) just simply always emit the JavaScript code which is responsible for the creation of the client-side JS objects for several JS-supported controls ("new Prado.WebUI.XXX()" lines at the end of the page). This is OK at initial page loads, but if this happens in a callback request, it leads to the creation of a new, redundant JavaScript client-side objects for controls _that already might have one (or more)_ JS client-side object instantiated for them, thus leading to multiple (possibly conflicting) client-side JS support objects living on the page for the affected controls. This in turn results in very odd and buggy behaviour on the client side, and might also seriously effect the server running the Prado application. In the worst case this leads to doubling the number of the actual client- side JS objects for every affected control, which not only makes the browser eat more and more memory after each callback, but can also make your server crawl and lead to unpredictable behaviour if any of the affected controls do callbacks themselves too, (either in response to user actions or due to timed callbacks and such), because now every one of those client-side JS objects will fire their own callbacks for that single Prado control. After 8 callbacks you will have 256 client-side JS objects for every single one of the affected DOM controls in the page! For ex. if you create an "active version" of TSlider and hook into its onChange event, where you initiate a callback back to your page, so you get notified when the user dragged the control, then - after executing your callback -Prado will send back a response to the client-side with a new "new Prado.WebUI.TSlider({'ID':...)" JavaScript block in it. This happens because TSlider calls TClientScriptManager::registerPostBackControl () from its onPreRender() method which gets executed at every page cycle (even at callbacks) and because registerPostBackControl() doesn't care either whether the slider is a newly created control (in which case it would be legitimate to create a client side TSlider JS object for it) or an already existing one (which already has a JS object created, up and running for it in the browser), but simply emits the code for the client- side TSlider Js-object creation ("new Prado.WebUI.TSlider...) again, thus creating a second JS object instance _for the very same object_ that not only already has one, but also was the control that initiated the callback cycle in the first place. Now, if you drag the slider, there will be 2 JS- side client objects monitoring and handling the control, even though that won't be apparent to you, because they all do the same thing. But when you release the slider, both of them will fire their onChange() events, thus resulting in not only one, but two callbacks to the server code - both returning a response which will create another two JS instances for the slider, thus resulting in 4 (!) JS objects handling the slider in total. If you drag the slider again, you will have 8, 16, 32, 64... JS-objects which all hook up to the same single slider control both on the page and also on the server side. Other controls might exhibit different behaviour due to the redundant objects and might lead to very weird effects. For ex. a control alternating between two states might become unable to be change it's state after the first change, as it - well, actually the JS objects linked to it - will always "see" an even number of events (2,4,8,16...) fired on it, thus resulting in the reversal of any attempt of change back to the original state. Controls which have a single well defined response and take a well-defined state for each user action, won't be crippled by the effects of this bug, because all their linked object-instances would send them into a state anyway, into which the first one sends them, thus resulting in no apparent glitch. For ex. even though TTabControl is also affected by this bug, it doesn't show any glitches, as no matter how many JS objects listen to the control's events, all of them will select the same tab for a click at a specific set of coordinates, and if the tab is already selected, then that won't result in any error either, so you won't even notice that there are now for ex. 32 client-side TTabControl objects handling your clicks on that single tab control in the DOM. OK, so much about the problem. Now, the solution. The bad new is: there isn't a simple one. A complete solution would require to extend TClientScriptManager::registerPostBackControl() (or it's callers) to keeps track of each control's state and only emit the JS code for them if either the current page cycle is an initial full page-load, the control gets replaced in the DOM by a new instance (because for ex. it was on a TActivePanel which got refreshed, or because it was an active control itself which got it's properties modified), or the control is a newly created one which has been constructed in the callback. If none of these are true, it should withhold the code for creating the client-side JS object for the control as there's already one of those at work in the browser. Implementing that will be though to, because of having to keep track of all the updates. The current implementation of several JS-supported non-active controls and/or of TClientScriptManager::registerPostBackControl() interferes with the active control / callback mechanism in Prado, as it doesn't care about the type of the actual page cycle and the state of the control. The problem is that nor registerPostBackControl() neither its callers care about whether the actual page-cycle is a full-page reload or just a callback, and they (actually registerPostBackControl()) just simply always emit the JavaScript code which is responsible for the creation of the client-side JS objects for several JS-supported controls ("new Prado.WebUI.XXX()" lines at the end of the page). This is OK at initial page loads, but if this happens in a callback request, it leads to the creation of a new, redundant JavaScript client-side objects for controls _that already might have one (or more)_ JS client-side object instantiated for them, thus leading to multiple (possibly conflicting) client-side JS support objects living on the page for the affected controls. This in turn results in very odd and buggy behaviour on the client side, and might also seriously effect the server running the Prado application. In the worst case this leads to doubling the number of the actual client- side JS objects for every affected control, which not only makes the browser eat more and more memory after each callback, but can also make your server crawl and lead to unpredictable behaviour if any of the affected controls do callbacks themselves too, (either in response to user actions or due to timed callbacks and such), because now every one of those client-side JS objects will fire their own callbacks for that single Prado control. After 8 callbacks you will have 256 client-side JS objects for every single one of the affected DOM controls in the page! For ex. if you create an "active version" of TSlider and hook into its onChange event, where you initiate a callback back to your page, so you get notified when the user dragged the control, then - after executing your callback -Prado will send back a response to the client-side with a new "new Prado.WebUI.TSlider({'ID':...)" JavaScript block in it. This happens because TSlider calls TClientScriptManager::registerPostBackControl () from its onPreRender() method which gets executed at every page cycle (even at callbacks) and because registerPostBackControl() doesn't care either whether the slider is a newly created control (in which case it would be legitimate to create a client side TSlider JS object for it) or an already existing one (which already has a JS object created, up and running for it in the browser), but simply emits the code for the client- side TSlider Js-object creation ("new Prado.WebUI.TSlider...) again, thus creating a second JS object instance _for the very same object_ that not only already has one, but also was the control that initiated the callback cycle in the first place. Now, if you drag the slider, there will be 2 JS- side client objects monitoring and handling the control, even though that won't be apparent to you, because they all do the same thing. But when you release the slider, both of them will fire their onChange() events, thus resulting in not only one, but two callbacks to the server code - both returning a response which will create another two JS instances for the slider, thus resulting in 4 (!) JS objects handling the slider in total. If you drag the slider again, you will have 8, 16, 32, 64... JS-objects which all hook up to the same single slider control both on the page and also on the server side. Other controls might exhibit different behaviour due to the redundant objects and might lead to very weird effects. For ex. a control alternating between two states might become unable to be change it's state after the first change, as it - well, actually the JS objects linked to it - will always "see" an even number of events (2,4,8,16...) fired on it, thus resulting in the reversal of any attempt of change back to the original state. Controls which have a single well defined response and take a well-defined state for each user action, won't be crippled by the effects of this bug, because all their linked object-instances would send them into a state anyway, into which the first one sends them, thus resulting in no apparent glitch. For ex. even though TTabControl is also affected by this bug, it doesn't show any glitches, as no matter how many JS objects listen to the control's events, all of them will select the same tab for a click at a specific set of coordinates, and if the tab is already selected, then that won't result in any error either, so you won't even notice that there are now for ex. 32 client-side TTabControl objects handling your clicks on that single tab control in the DOM. OK, so much about the problem. Now, the solution. The bad new is: there isn't a simple one. A complete solution would require to extend TClientScriptManager::registerPostBackControl() (or it's callers) to keeps track of each control's state and only emit the JS code for them if either the current page cycle is an initial full page-load, the control gets replaced in the DOM by a new instance (because for ex. it was on a TActivePanel which got refreshed, or because it was an active control itself which got it's properties modified), or the control is a newly created one which has been constructed in the callback. If none of these are true, it should withhold the code for creating the client-side JS object for the control as there's already one of those at work in the browser. Implementing that will be though to, because of having to keep track of all the updates. Jun 19, 2009 issue 180 (Integrate XMLRPC web service) Labels changed by Christophe.Boulain - Labels: Type-Enhancement Priority-Low Milestone-3.2a −Type-Defect −Priority-Medium −Milestone-3.1.6 Labels: Type-Enhancement Priority-Low Milestone-3.2a −Type-Defect −Priority-Medium −Milestone-3.1.6 Jun 19, 2009 issue 180 (Integrate XMLRPC web service) commented on by j...@letux.ch - should be moved in the milestone-3.2 should be moved in the milestone-3.2 Jun 19, 2009 issue 180 (Integrate XMLRPC web service) reported by j...@letux.ch - See the following thread: http://www.pradosoft.com/forum/index.php/topic,11888.0.html See the following thread: http://www.pradosoft.com/forum/index.php/topic,11888.0.html Jun 18, 2009 issue 179 (Serialization issues in Prado) reported by google...@pcforum.hu - While testing some serialization-related issues in Prado I've discovered a few anomalies in the standard libraries. The most obvious one is that even though PradoBase defines a serialize ()/deserialize() method for circumventing a PHP bug, at most places in the code it simply calls the original serialize()/unserialize() functions, which makes little sense to me. The places include TApplication's, TCachePageStatePersister's save() and load() methods, and various methods of TCache and TOutputCache. I'm not sure whether the bug the work-around was created for still exists in PHP, but it makes little sense to me to have the original functions called with the extra methods defined in PradoBase. Also there are places where data saved to and restored from persistent storage gets 'double escaped' by calling serialize consecutively more than once on them, which wastes CPU time. Most prominent examples of that are TCachePageStatePersister's load() and save() methods, which call serialize () and unserialize() on the data passed to and retrieve from the applications cache's add() and get() methods, even though the latter ones call serialize()/unserialize() on the data anyway, so they could accept the raw data just as good, and thus avoid an unneccessary call to the serialize()/unserialize() pair. ---- I also honestly don't really understand why does TCache::get() and set() unserialize/serialize the data, and why doesn't it leave that just up to the actual cache implementation - if that needs it, because for example some accelerators' caching functions can accept raw object references too, so there's no need for - a most probably extra - serialization before passing the values to them. In my opinion it should be the actual cache implementation, that decides over whether to serialize or not prior to storage (in their respective to-be-overridden methods getValue()/setValue ()/etc.) not the general TCache class in it's public get()/set() methods, which knows nothing about the cache's backend's actual capabilities. Also this way the cache has no way to for ex. make caching decisions based on the type of the data stored. For ex. someone might want to create a "hybrid" cache which stores parsed templates in files (as the overall size of these might grow very large and have statistically bad hit ratios) and session/pagestate data using some shared-memory approach (as these might get high cache-hit ratios), but has currently no way to implement such a cache (without re-implementing TCache's get()/set() methods), as the custom methods supposed to be overridden by caches (getValue()/setValue ()/etc) already get all cache entries in a type-neutral, unprocessable serialized format, which makes it impossible to effectively figure out anything about the type of those entries (without deserializing them, of course, which would waste CPU time again). Changing that behaviour (ie. leave serialization up to - if neccessary - to the actual cache implementations) would probably break compatibility with existing non-standard TCache-descendants (as some of those might rely on the getting data already serialized), and this issue isn't my primary concern either, I just mentioned it, because it's generally a bad design decision/approach in my opinion. While testing some serialization-related issues in Prado I've discovered a few anomalies in the standard libraries. The most obvious one is that even though PradoBase defines a serialize ()/deserialize() method for circumventing a PHP bug, at most places in the code it simply calls the original serialize()/unserialize() functions, which makes little sense to me. The places include TApplication's, TCachePageStatePersister's save() and load() methods, and various methods of TCache and TOutputCache. I'm not sure whether the bug the work-around was created for still exists in PHP, but it makes little sense to me to have the original functions called with the extra methods defined in PradoBase. Also there are places where data saved to and restored from persistent storage gets 'double escaped' by calling serialize consecutively more than once on them, which wastes CPU time. Most prominent examples of that are TCachePageStatePersister's load() and save() methods, which call serialize () and unserialize() on the data passed to and retrieve from the applications cache's add() and get() methods, even though the latter ones call serialize()/unserialize() on the data anyway, so they could accept the raw data just as good, and thus avoid an unneccessary call to the serialize()/unserialize() pair. ---- I also honestly don't really understand why does TCache::get() and set() unserialize/serialize the data, and why doesn't it leave that just up to the actual cache implementation - if that needs it, because for example some accelerators' caching functions can accept raw object references too, so there's no need for - a most probably extra - serialization before passing the values to them. In my opinion it should be the actual cache implementation, that decides over whether to serialize or not prior to storage (in their respective to-be-overridden methods getValue()/setValue ()/etc.) not the general TCache class in it's public get()/set() methods, which knows nothing about the cache's backend's actual capabilities. Also this way the cache has no way to for ex. make caching decisions based on the type of the data stored. For ex. someone might want to create a "hybrid" cache which stores parsed templates in files (as the overall size of these might grow very large and have statistically bad hit ratios) and session/pagestate data using some shared-memory approach (as these might get high cache-hit ratios), but has currently no way to implement such a cache (without re-implementing TCache's get()/set() methods), as the custom methods supposed to be overridden by caches (getValue()/setValue ()/etc) already get all cache entries in a type-neutral, unprocessable serialized format, which makes it impossible to effectively figure out anything about the type of those entries (without deserializing them, of course, which would waste CPU time again). Changing that behaviour (ie. leave serialization up to - if neccessary - to the actual cache implementations) would probably break compatibility with existing non-standard TCache-descendants (as some of those might rely on the getting data already serialized), and this issue isn't my primary concern either, I just mentioned it, because it's generally a bad design decision/approach in my opinion. Jun 16, 2009 issue 178 (TActiveFileUpload progress indicator is misleading) reported by google...@pcforum.hu - The current implementation of TActiveFileUpload's progress indicator is misleading as it signals completion of the file upload already then, when only the file has been transferred to the server, but the callback for the control hasn't been completed yet. If the latter one takes more than a fraction of a second (for ex. because you want run a virus scan against the newly uploaded file or do some other processing - like resizing an image or whatever -, then the user is mislead into believing of successful completion of the file upload, when the server might actually reject the download in the callback. (which is technically true, as the contents of the file have been actually transferred to the server side, only, the contents of the file didn't get processed yet, nor did the server code get the change to do anything with that file yet, what the user really cares about, in my opinion and in common sense) This also generates a pure technical problem (beyond UI design), because till the callback doesn't return the file upload control stalls in an undefined state, in which trying to re-use it for uploading another file or progress from the current page to another one might result in unpredictable behaviour, both on server side, and also on the client (for ex. you can get javascript errors when you try to proceed from the current page while the callback is in progress). Therefore I've modified the original activeupload.js file (see attachment, original base from 3.1.5) to have an extra step/state after the file upload, when the callback is occouring, and only set the status of the upload control upon completion (either with success or failure) of that callback. This gives a more accurate status feedback to the user regarding the upload process and also prevents concurrency errors resulting from the misleading status display. The modifications should be fully backward compatible with existing prado code and can be used as a drop-in replacement for the original javascript file for the control. The current implementation of TActiveFileUpload's progress indicator is misleading as it signals completion of the file upload already then, when only the file has been transferred to the server, but the callback for the control hasn't been completed yet. If the latter one takes more than a fraction of a second (for ex. because you want run a virus scan against the newly uploaded file or do some other processing - like resizing an image or whatever -, then the user is mislead into believing of successful completion of the file upload, when the server might actually reject the download in the callback. (which is technically true, as the contents of the file have been actually transferred to the server side, only, the contents of the file didn't get processed yet, nor did the server code get the change to do anything with that file yet, what the user really cares about, in my opinion and in common sense) This also generates a pure technical problem (beyond UI design), because till the callback doesn't return the file upload control stalls in an undefined state, in which trying to re-use it for uploading another file or progress from the current page to another one might result in unpredictable behaviour, both on server side, and also on the client (for ex. you can get javascript errors when you try to proceed from the current page while the callback is in progress). Therefore I've modified the original activeupload.js file (see attachment, original base from 3.1.5) to have an extra step/state after the file upload, when the callback is occouring, and only set the status of the upload control upon completion (either with success or failure) of that callback. This gives a more accurate status feedback to the user regarding the upload process and also prevents concurrency errors resulting from the misleading status display. The modifications should be fully backward compatible with existing prado code and can be used as a drop-in replacement for the original javascript file for the control. Jun 16, 2009 issue 177 (THttpResponse::setStatusCode() has no effect) reported by google...@pcforum.hu - What steps will reproduce the problem? 1. Create a Prado application with a single page 2. Try to set response status code while serving up the page 3. Run the application requesting the page constructed above What is the expected output? What do you see instead? Prado should serve up the status code and text supplied to the THttpResponse::setStatusCode() call in the first row of the HTTP header returned to the client (browser). However, this is not the case, and an empty page with status code 200 (OK) is served up, no matter what. No warnings or errors are emitted whatsoever. What version of the product are you using? On what operating system? Prado/3.1.5, Apache 2.2.11 Please provide any additional information below. It doesn't really matter where you try to set the status code. Placing THttpResponse::setStatusCode() into the page's OnInit(), OnPreRender() or render() method all have the same effect: none, at least in regard of the HTTP response header generated, as that will stay 200 - OK, no matter what. What steps will reproduce the problem? 1. Create a Prado application with a single page 2. Try to set response status code while serving up the page 3. Run the application requesting the page constructed above What is the expected output? What do you see instead? Prado should serve up the status code and text supplied to the THttpResponse::setStatusCode() call in the first row of the HTTP header returned to the client (browser). However, this is not the case, and an empty page with status code 200 (OK) is served up, no matter what. No warnings or errors are emitted whatsoever. What version of the product are you using? On what operating system? Prado/3.1.5, Apache 2.2.11 Please provide any additional information below. It doesn't really matter where you try to set the status code. Placing THttpResponse::setStatusCode() into the page's OnInit(), OnPreRender() or render() method all have the same effect: none, at least in regard of the HTTP response header generated, as that will stay 200 - OK, no matter what. Jun 15, 2009 issue 176 (Feature Request: Provide a way to supply download filename t...) reported by google...@pcforum.hu - Please add a 5th, optional parameter to THttpResponse::writeFile(), where we can supply a filename for use in the "Content-Disposition" header field of the response. Currently, the filename is derived from the basename of the 1st parameter, which actually contains the local path of the file to be sent - but there are cases where an application want might to provide a different default name for the file to be saved. For ex. files might be stored under a random-generated filename on the server-side by the application to prevent any possible (file)name-based attacks by users of the site (much like files in the browser cache are stored in random-named directories), but we still might want to provide the user with the original name of the file when offering it to download. Currently, however, this is not possible, as the writeFile() method doesn't provide us a way to supply a default filename other than that of the name of the local file we want to sent. But by changing public function writeFile ($fileName,$content=null,$mimeType=null,$headers=null) to public function writeFile ($fileName,$content=null,$mimeType=null,$headers=null,$saveName=null) and $fn=basename($fileName); to if (!$saveName) $fn = basename($fileName); else $fn = $saveName; the method can be easily extended to provide that functionality too. PS: Please don't tell me to simply load the contents of the file with file_get_contents() and supply it as the 2nd parameter to writeFile() while using the 1st param as the filename, because the memory footprint of that solution exceeds far that of a "regular" file download, as it requires PHP to actually load all of the file into the memory (which might be hundreds of MBs with a larger download), instead of just passing it to the output in block chunks, like it does with readfile(). Please add a 5th, optional parameter to THttpResponse::writeFile(), where we can supply a filename for use in the "Content-Disposition" header field of the response. Currently, the filename is derived from the basename of the 1st parameter, which actually contains the local path of the file to be sent - but there are cases where an application want might to provide a different default name for the file to be saved. For ex. files might be stored under a random-generated filename on the server-side by the application to prevent any possible (file)name-based attacks by users of the site (much like files in the browser cache are stored in random-named directories), but we still might want to provide the user with the original name of the file when offering it to download. Currently, however, this is not possible, as the writeFile() method doesn't provide us a way to supply a default filename other than that of the name of the local file we want to sent. But by changing public function writeFile ($fileName,$content=null,$mimeType=null,$headers=null) to public function writeFile ($fileName,$content=null,$mimeType=null,$headers=null,$saveName=null) and $fn=basename($fileName); to if (!$saveName) $fn = basename($fileName); else $fn = $saveName; the method can be easily extended to provide that functionality too. PS: Please don't tell me to simply load the contents of the file with file_get_contents() and supply it as the 2nd parameter to writeFile() while using the 1st param as the filename, because the memory footprint of that solution exceeds far that of a "regular" file download, as it requires PHP to actually load all of the file into the memory (which might be hundreds of MBs with a larger download), instead of just passing it to the output in block chunks, like it does with readfile(). Jun 15, 2009 r2679 (Primilary import of new db stuff) committed by Christophe.Boulain - Primilary import of new db stuff Primilary import of new db stuff Jun 07, 2009 r2678 (Merging latest 3.1 changes into trunk (r2672-2677)) committed by godzill...@gmx.net - Merging latest 3.1 changes into trunk (r2672-2677) Merging latest 3.1 changes into trunk (r2672-2677) Jun 07, 2009 issue 174 (HTTP error messages contains sensitive information) changed by godzill...@gmx.net - Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement Security −Type-Defect Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement Security −Type-Defect Jun 07, 2009 r2677 (Fixed Issue#174 - TErrorHandler: HTTP error messages contain...) committed by godzill...@gmx.net - Fixed Issue#174 - TErrorHandler: HTTP error messages contains sensitive information Fixed Issue#174 - TErrorHandler: HTTP error messages contains sensitive information Jun 07, 2009 r2676 (Enhancement: TFirePhpLogRoute: bypass to TBrowserLogRoute if...) committed by godzill...@gmx.net - Enhancement: TFirePhpLogRoute: bypass to TBrowserLogRoute if headers already sent / php.ini (output_buffering=Off, implicit_flush=On) Enhancement: TFirePhpLogRoute: bypass to TBrowserLogRoute if headers already sent / php.ini (output_buffering=Off, implicit_flush=On) Jun 07, 2009 issue 168 (CacheModel properties in SQLMap are not updated) changed by godzill...@gmx.net - Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Jun 07, 2009 r2675 (Fixed Issue #168 - TSqlMapXmlConfiguration: CacheModel prope...) committed by godzill...@gmx.net - Fixed Issue #168 - TSqlMapXmlConfiguration: CacheModel properties are not set Fixed Issue #168 - TSqlMapXmlConfiguration: CacheModel properties are not set Jun 07, 2009 r2674 (enhancement: introduce protected property "Published" in TAs...) committed by godzill...@gmx.net - enhancement: introduce protected property "Published" in TAssetManager to allow subclasses access enhancement: introduce protected property "Published" in TAssetManager to allow subclasses access Jun 07, 2009 issue 175 (RFE - TBulletStyle::None) changed by godzill...@gmx.net - Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Fixed in https://prado3.googlecode.com/svn/branches/3.1 Status: Fixed Owner: godzill...@gmx.net Labels: Type-Enhancement −Type-Defect Jun 07, 2009 r2673 (Fixed Issue#175 - TBulletedList: Introduce TBulletStyle::Non...) committed by godzill...@gmx.net - Fixed Issue#175 - TBulletedList: Introduce TBulletStyle::None Fixed Issue#175 - TBulletedList: Introduce TBulletStyle::None Jun 05, 2009 issue 175 (RFE - TBulletStyle::None) reported by cross+go...@distal.com - Please provide any additional information below. The CSS 'list-style-type' which is used by TBulletedList and set based on the value of the controls BulletStyle does not allow for setting the list-style-type to None. (ie, no bullet). Please add this feature. Simply adding TBulletStyle::None to the TEnumerable and adding 4 lines of code in TBulletedList::addAttributesToRender() should be all that are necessary. Thank you. Please provide any additional information below. The CSS 'list-style-type' which is used by TBulletedList and set based on the value of the controls BulletStyle does not allow for setting the list-style-type to None. (ie, no bullet). Please add this feature. Simply adding TBulletStyle::None to the TEnumerable and adding 4 lines of code in TBulletedList::addAttributesToRender() should be all that are necessary. Thank you. Jun 05, 2009 issue 117 (enhancement: empower TValidationSummary to render HeaderText...) commented on by godzill...@gmx.net - Fixed in https://prado3.googlecode.com/svn/branches/3.1 Fixed in https://prado3.googlecode.com/svn/branches/3.1 Jun 05, 2009 r2672 (Fix Issue#117 - Consider TValidationSummary.DisplayMode="Hea...) committed by godzill...@gmx.net - Fix Issue#117 - Consider TValidationSummary.DisplayMode="HeaderOnly" if TValidationSummary.ShowMessageBox is set Fix Issue#117 - Consider TValidationSummary.DisplayMode="HeaderOnly" if TValidationSummary.ShowMessageBox is set Jun 05, 2009 issue 174 (HTTP error messages contains sensitive information) reported by daniel.fruzynski - What steps will reproduce the problem? 1. Set app mode to Normal 2. Spoil something in code so HTTP error 500 will be generated 3. Check HTTP header sent by server What is the expected output? What do you see instead? Current error message: HTTP/1.0 500 Unknown component type 'TLogRouterr'. This may be caused by the following parsing error in the TLogRouterr class file: [Warning] include_once(C:\poradnik-webmastera.local\includes\prado\Util\TLogRouterr.php) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory (@line 287 in file C:\poradnik-webmastera.local\includes\prado\PradoBase.php). Expected error message: HTTP/1.0 500 Internal Server Error This happens for other error codes too (I recall 404 now). There is no point to put whole error message to HTTP response (it is also displayed on page in Debug mode), so I advice to change these error messages to generic, e.g. taken from RFC. Alternatively you can use current ones them in Debug mode, and replace them in production modes. What version of the product are you using? On what operating system? prado 3.1.4, windows xp Please provide any additional information below. What steps will reproduce the problem? 1. Set app mode to Normal 2. Spoil something in code so HTTP error 500 will be generated 3. Check HTTP header sent by server What is the expected output? What do you see instead? Current error message: HTTP/1.0 500 Unknown component type 'TLogRouterr'. This may be caused by the following parsing error in the TLogRouterr class file: [Warning] include_once(C:\poradnik-webmastera.local\includes\prado\Util\TLogRouterr.php) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory (@line 287 in file C:\poradnik-webmastera.local\includes\prado\PradoBase.php). Expected error message: HTTP/1.0 500 Internal Server Error This happens for other error codes too (I recall 404 now). There is no point to put whole error message to HTTP response (it is also displayed on page in Debug mode), so I advice to change these error messages to generic, e.g. taken from RFC. Alternatively you can use current ones them in Debug mode, and replace them in production modes. What version of the product are you using? On what operating system? prado 3.1.4, windows xp Please provide any additional information below. Earlier this year Jun 02, 2009 issue 117 (enhancement: empower TValidationSummary to render HeaderText...) commented on by leandrogarber - I think it would be useful if ShowMessageBox is true and DisplayMode is "HeaderOnly" then the messagebox should show only the header I think it would be useful if ShowMessageBox is true and DisplayMode is "HeaderOnly" then the messagebox should show only the header Jun 02, 2009 r2671 (Merging latest 3.1 changes into trunk) committed by Christophe.Boulain - Merging latest 3.1 changes into trunk Merging latest 3.1 changes into trunk Jun 02, 2009 issue 98 (Missing file in prado-3.1.4 source zip: TDropContainer & TDr...) Status changed by Christophe.Boulain - This issue was closed by r2670. Status: Fixed This issue was closed by r2670. Status: Fixed Jun 02, 2009 r2670 (Rename assets folder in Drag&Drop demo so it will be present...) committed by Christophe.Boulain - Rename assets folder in Drag&Drop demo so it will be present in next prado release. Fixed Issue#98 Rename assets folder in Drag&Drop demo so it will be present in next prado release. Fixed Issue#98 Jun 02, 2009 issue 173 (Improvement: coordinates and key status for drag&drop) changed by Christophe.Boulain - Status: Accepted Owner: Christophe.Boulain Labels: Type-Enhancement Milestone-3.2a −Type-Defect −Milestone-3.1.6 Status: Accepted Owner: Christophe.Boulain Labels: Type-Enhancement Milestone-3.2a −Type-Defect −Milestone-3.1.6 Jun 01, 2009 issue 151 (TTextBox fails to display inital blank line) changed by godzill...@gmx.net - Status: New Labels: Milestone-3.1.6 −Milestone-3.1.5 Status: New Labels: Milestone-3.1.6 −Milestone-3.1.5 Jun 01, 2009 issue 151 (TTextBox fails to display inital blank line) commented on by cross+go...@distal.com - Any feedback on this? The inconsistent and/or unexpected results I describe above I think still make this a bug requiring investigation. Please let me know if there's any more information I can provide to help describe the problems. Thank you. Any feedback on this? The inconsistent and/or unexpected results I describe above I think still make this a bug requiring investigation. Please let me know if there's any more information I can provide to help describe the problems. Thank you. Jun 01, 2009 issue 173 (Improvement: coordinates and key status for drag&drop) reported by google...@pcforum.hu - I've added coordinates and key status (shift, ctrl, alt) support for drag&drop operations in Prado. Simply replace the original 3.1.5 distribution files with the supplied ones, to get a new enhanced TDropContainer, which - if required - also supplies the client coordinates and key status of drop events. This enables you to add richer functionality to your Prado application. To ensure maximum compatibility I've modified the files in a way that all original functionality is preserved, but also a new OnDropEx event is created, which receives the extra information (X and Y coordinates of drop and ShiftKey, AltKey CtrlKey to tell whether the user held down the specified keys when the draggable was dropped). The OnDrop and OnCallback event handlers will still receive all parameters in the old format. It should be considered to change this behaviour (at least in the case of the OnCallback handlers, but maybe also the OnDrop handler, which now goes against good practice and receives just the drop target id instead of a full param object, which forced me to create a new handler so I don't break compatibility), but I leave this decision up to the Prado core developers if they commit my changes to the core trunk. Tested with IE8/FF35/Chrome2/Safari32. Also works in Opera10, but drag and drop (even the original implementation) is basically messed up in that one (draggable not visible outside of parent element; draggable doesn't revert to right position after release; etc). I've added coordinates and key status (shift, ctrl, alt) support for drag&drop operations in Prado. Simply replace the original 3.1.5 distribution files with the supplied ones, to get a new enhanced TDropContainer, which - if required - also supplies the client coordinates and key status of drop events. This enables you to add richer functionality to your Prado application. To ensure maximum compatibility I've modified the files in a way that all original functionality is preserved, but also a new OnDropEx event is created, which receives the extra information (X and Y coordinates of drop and ShiftKey, AltKey CtrlKey to tell whether the user held down the specified keys when the draggable was dropped). The OnDrop and OnCallback event handlers will still receive all parameters in the old format. It should be considered to change this behaviour (at least in the case of the OnCallback handlers, but maybe also the OnDrop handler, which now goes against good practice and receives just the drop target id instead of a full param object, which forced me to create a new handler so I don't break compatibility), but I leave this decision up to the Prado core developers if they commit my changes to the core trunk. Tested with IE8/FF35/Chrome2/Safari32. Also works in Opera10, but drag and drop (even the original implementation) is basically messed up in that one (draggable not visible outside of parent element; draggable doesn't revert to right position after release; etc). Jun 01, 2009 issue 172 (TDbCache fails to recognize need to create cache table) changed by godzill...@gmx.net - Status: Accepted Owner: godzill...@gmx.net Status: Accepted Owner: godzill...@gmx.net May 31, 2009 issue 172 (TDbCache fails to recognize need to create cache table) reported by google...@pcforum.hu - What steps will reproduce the problem? 1. Create a new Prado application using TDbCache 2. Run the application once 3. Drop the cache table from the database using a command-line/admin tool 4. Run the application again What is the expected output? What do you see instead? The program should execute normally (as it did in 3.1.4 and prior version) by detecting and re-creating the missing cache table. Instead it fails with a "TDbCommand failed to execute the SQL statement DELETE FROM z_cache..." fatal error. This is due to TDbCache failing to recognize that the cache table has been dropped in the meantime (as the quickest solution to clear the cache, for ex.). What version of the product are you using? On what operating system? Prado/3.1.5 Please provide any additional information below. The problem lies with TDbCache.initializeCache() relying on a state variable set in the global (persistent) application state namespace and signaling the creating of the cache table, which if once set, will be never cleared and the existence of the cache table will never be checked again - not even in the case of an error when trying to access it. In previous Prado versions if the first operation on the cache table failed, the TDbCache class tried to re-create the cache table first, and only if this didn't succeed either, did it emit an error message. Now however, as stated above, the new TDbCache implementation checks only at the first ever run of an application using TDbCache whether the cache table actually exists and doesn't ever consider re-checking or trying to re-create it, even if an attempt to access the table fails (except when you change the name of the table in the application config). If, for whetever reason you need to recreate the underlying database of the application or simply just drop the cache table, your application will end up in a state where it can't recover from, unless you manually delete the global application state store "global.cache" under "runtime/application.xml-x.y.z" (which will also reset all other persistent variable for your application too). I think the old behaviour should be brought back, meaning that if an attempt to access the cache table fails with an error, the table should be checked for existence, and if needed re-created and the original operation retried. What steps will reproduce the problem? 1. Create a new Prado application using TDbCache 2. Run the application once 3. Drop the cache table from the database using a command-line/admin tool 4. Run the application again What is the expected output? What do you see instead? The program should execute normally (as it did in 3.1.4 and prior version) by detecting and re-creating the missing cache table. Instead it fails with a "TDbCommand failed to execute the SQL statement DELETE FROM z_cache..." fatal error. This is due to TDbCache failing to recognize that the cache table has been dropped in the meantime (as the quickest solution to clear the cache, for ex.). What version of the product are you using? On what operating system? Prado/3.1.5 Please provide any additional information below. The problem lies with TDbCache.initializeCache() relying on a state variable set in the global (persistent) application state namespace and signaling the creating of the cache table, which if once set, will be never cleared and the existence of the cache table will never be checked again - not even in the case of an error when trying to access it. In previous Prado versions if the first operation on the cache table failed, the TDbCache class tried to re-create the cache table first, and only if this didn't succeed either, did it emit an error message. Now however, as stated above, the new TDbCache implementation checks only at the first ever run of an application using TDbCache whether the cache table actually exists and doesn't ever consider re-checking or trying to re-create it, even if an attempt to access the table fails (except when you change the name of the table in the application config). If, for whetever reason you need to recreate the underlying database of the application or simply just drop the cache table, your application will end up in a state where it can't recover from, unless you manually delete the global application state store "global.cache" under "runtime/application.xml-x.y.z" (which will also reset all other persistent variable for your application too). I think the old behaviour should be brought back, meaning that if an attempt to access the cache table fails with an error, the table should be checked for existence, and if needed re-created and the original operation retried. May 31, 2009 issue 171 (<connection> tag in SqlMap config ignored in 3.1.5) reported by google...@pcforum.hu - What steps will reproduce the problem? 1. Create a Prado application using SqlMap config file 2. Put <connection class="TDbConnection" ConnectionString="xxx" Username="abc" Password="efg" /> in the main SqlMap config to set database properties 3. Try to run the application and access the database using an SqlMap query What is the expected output? What do you see instead? The application and the query runs just fine under 3.1.4 or earlier Prado version, but fails under 3.1.5 with a "TDbConnection failed to establish DB connection: invalid data source name" exception. Debugging reveals that the cause is that "$this->getUsername()", "$this->getPassword()", etc. all return empty strings at the "$this->_pdo=new PDO(...);" call in TDbConnection.open(), meaning either the <connection> tag isn't parsed or it's properties aren't stored properly. However, if you set the connection properties in the application.xml configuration file by including a <database ConnectionString="xxx" Username="abc" Password="efg" /> inside the <module> tag that loads the SqlMap configuration, the connection properties will be set properly and the SqlMap queries will be executed fine. What version of the product are you using? On what operating system? Prado/3.1.5 Please provide any additional information below. The bug was present in the SVN trunk for quite a while now (so it might have been introduced shortly after releasing 3.1.4), I just thought it would be so obvious, that it wouldn't make it in the final 3.1.5 release, so didn't report it. What steps will reproduce the problem? 1. Create a Prado application using SqlMap config file 2. Put <connection class="TDbConnection" ConnectionString="xxx" Username="abc" Password="efg" /> in the main SqlMap config to set database properties 3. Try to run the application and access the database using an SqlMap query What is the expected output? What do you see instead? The application and the query runs just fine under 3.1.4 or earlier Prado version, but fails under 3.1.5 with a "TDbConnection failed to establish DB connection: invalid data source name" exception. Debugging reveals that the cause is that "$this->getUsername()", "$this->getPassword()", etc. all return empty strings at the "$this->_pdo=new PDO(...);" call in TDbConnection.open(), meaning either the <connection> tag isn't parsed or it's properties aren't stored properly. However, if you set the connection properties in the application.xml configuration file by including a <database ConnectionString="xxx" Username="abc" Password="efg" /> inside the <module> tag that loads the SqlMap configuration, the connection properties will be set properly and the SqlMap queries will be executed fine. What version of the product are you using? On what operating system? Prado/3.1.5 Please provide any additional information below. The bug was present in the SVN trunk for quite a while now (so it might have been introduced shortly after releasing 3.1.4), I just thought it would be so obvious, that it wouldn't make it in the final 3.1.5 release, so didn't report it. May 30, 2009 issue 170 (Call to undefined method TApplication::getConfigurationType(...) Status changed by godzill...@gmx.net - Set status to Invalid since pradolite.php is not part of repository! File will be generate in build process and therefor only available in releases e.g. 3.1.5 Status: Invalid Set status to Invalid since pradolite.php is not part of repository! File will be generate in build process and therefor only available in releases e.g. 3.1.5 Status: Invalid

issue 181 (Prado client-side flawed - aka Multiple client-side (JS) obj...) reported by google...@pcforum.hu - The current implementation of several JS-supported non-active controls and/or of TClientScriptManager::registerPostBackControl() interferes with the active control / callback mechanism in Prado, as it doesn't care about the type of the actual page cycle and the state of the control. The problem is that nor registerPostBackControl() neither its callers care about whether the actual page-cycle is a full-page reload or just a callback, and they (actually registerPostBackControl()) just simply always emit the JavaScript code which is responsible for the creation of the client-side JS objects for several JS-supported controls ("new Prado.WebUI.XXX()" lines at the end of the page). This is OK at initial page loads, but if this happens in a callback request, it leads to the creation of a new, redundant JavaScript client-side objects for controls _that already might have one (or more)_ JS client-side object instantiated for them, thus leading to multiple (possibly conflicting) client-side JS support objects living on the page for the affected controls. This in turn results in very odd and buggy behaviour on the client side, and might also seriously effect the server running the Prado application. In the worst case this leads to doubling the number of the actual client- side JS objects for every affected control, which not only makes the browser eat more and more memory after each callback, but can also make your server crawl and lead to unpredictable behaviour if any of the affected controls do callbacks themselves too, (either in response to user actions or due to timed callbacks and such), because now every one of those client-side JS objects will fire their own callbacks for that single Prado control. After 8 callbacks you will have 256 client-side JS objects for every single one of the affected DOM controls in the page! For ex. if you create an "active version" of TSlider and hook into its onChange event, where you initiate a callback back to your page, so you get notified when the user dragged the control, then - after executing your callback -Prado will send back a response to the client-side with a new "new Prado.WebUI.TSlider({'ID':...)" JavaScript block in it. This happens because TSlider calls TClientScriptManager::registerPostBackControl () from its onPreRender() method which gets executed at every page cycle (even at callbacks) and because registerPostBackControl() doesn't care either whether the slider is a newly created control (in which case it would be legitimate to create a client side TSlider JS object for it) or an already existing one (which already has a JS object created, up and running for it in the browser), but simply emits the code for the client- side TSlider Js-object creation ("new Prado.WebUI.TSlider...) again, thus creating a second JS object instance _for the very same object_ that not only already has one, but also was the control that initiated the callback cycle in the first place. Now, if you drag the slider, there will be 2 JS- side client objects monitoring and handling the control, even though that won't be apparent to you, because they all do the same thing. But when you release the slider, both of them will fire their onChange() events, thus resulting in not only one, but two callbacks to the server code - both returning a response which will create another two JS instances for the slider, thus resulting in 4 (!) JS objects handling the slider in total. If you drag the slider again, you will have 8, 16, 32, 64... JS-objects which all hook up to the same single slider control both on the page and also on the server side. Other controls might exhibit different behaviour due to the redundant objects and might lead to very weird effects. For ex. a control alternating between two states might become unable to be change it's state after the first change, as it - well, actually the JS objects linked to it - will always "see" an even number of events (2,4,8,16...) fired on it, thus resulting in the reversal of any attempt of change back to the original state. Controls which have a single well defined response and take a well-defined state for each user action, won't be crippled by the effects of this bug, because all their linked object-instances would send them into a state anyway, into which the first one sends them, thus resulting in no apparent glitch. For ex. even though TTabControl is also affected by this bug, it doesn't show any glitches, as no matter how many JS objects listen to the control's events, all of them will select the same tab for a click at a specific set of coordinates, and if the tab is already selected, then that won't result in any error either, so you won't even notice that there are now for ex. 32 client-side TTabControl objects handling your clicks on that single tab control in the DOM. OK, so much about the problem. Now, the solution. The bad new is: there isn't a simple one. A complete solution would require to extend TClientScriptManager::registerPostBackControl() (or it's callers) to keeps track of each control's state and only emit the JS code for them if either the current page cycle is an initial full page-load, the control gets replaced in the DOM by a new instance (because for ex. it was on a TActivePanel which got refreshed, or because it was an active control itself which got it's properties modified), or the control is a newly created one which has been constructed in the callback. If none of these are true, it should withhold the code for creating the client-side JS object for the control as there's already one of those at work in the browser. Implementing that will be though to, because of having to keep track of all the updates.

The current implementation of several JS-supported non-active controls and/or of TClientScriptManager::registerPostBackControl() interferes with the active control / callback mechanism in Prado, as it doesn't care about the type of the actual page cycle and the state of the control. The problem is that nor registerPostBackControl() neither its callers care about whether the actual page-cycle is a full-page reload or just a callback, and they (actually registerPostBackControl()) just simply always emit the JavaScript code which is responsible for the creation of the client-side JS objects for several JS-supported controls ("new Prado.WebUI.XXX()" lines at the end of the page). This is OK at initial page loads, but if this happens in a callback request, it leads to the creation of a new, redundant JavaScript client-side objects for controls _that already might have one (or more)_ JS client-side object instantiated for them, thus leading to multiple (possibly conflicting) client-side JS support objects living on the page for the affected controls. This in turn results in very odd and buggy behaviour on the client side, and might also seriously effect the server running the Prado application. In the worst case this leads to doubling the number of the actual client- side JS objects for every affected control, which not only makes the browser eat more and more memory after each callback, but can also make your server crawl and lead to unpredictable behaviour if any of the affected controls do callbacks themselves too, (either in response to user actions or due to timed callbacks and such), because now every one of those client-side JS objects will fire their own callbacks for that single Prado control. After 8 callbacks you will have 256 client-side JS objects for every single one of the affected DOM controls in the page! For ex. if you create an "active version" of TSlider and hook into its onChange event, where you initiate a callback back to your page, so you get notified when the user dragged the control, then - after executing your callback -Prado will send back a response to the client-side with a new "new Prado.WebUI.TSlider({'ID':...)" JavaScript block in it. This happens because TSlider calls TClientScriptManager::registerPostBackControl () from its onPreRender() method which gets executed at every page cycle (even at callbacks) and because registerPostBackControl() doesn't care either whether the slider is a newly created control (in which case it would be legitimate to create a client side TSlider JS object for it) or an already existing one (which already has a JS object created, up and running for it in the browser), but simply emits the code for the client- side TSlider Js-object creation ("new Prado.WebUI.TSlider...) again, thus creating a second JS object instance _for the very same object_ that not only already has one, but also was the control that initiated the callback cycle in the first place. Now, if you drag the slider, there will be 2 JS- side client objects monitoring and handling the control, even though that won't be apparent to you, because they all do the same thing. But when you release the slider, both of them will fire their onChange() events, thus resulting in not only one, but two callbacks to the server code - both returning a response which will create another two JS instances for the slider, thus resulting in 4 (!) JS objects handling the slider in total. If you drag the slider again, you will have 8, 16, 32, 64... JS-objects which all hook up to the same single slider control both on the page and also on the server side. Other controls might exhibit different behaviour due to the redundant objects and might lead to very weird effects. For ex. a control alternating between two states might become unable to be change it's state after the first change, as it - well, actually the JS objects linked to it - will always "see" an even number of events (2,4,8,16...) fired on it, thus resulting in the reversal of any attempt of change back to the original state. Controls which have a single well defined response and take a well-defined state for each user action, won't be crippled by the effects of this bug, because all their linked object-instances would send them into a state anyway, into which the first one sends them, thus resulting in no apparent glitch. For ex. even though TTabControl is also affected by this bug, it doesn't show any glitches, as no matter how many JS objects listen to the control's events, all of them will select the same tab for a click at a specific set of coordinates, and if the tab is already selected, then that won't result in any error either, so you won't even notice that there are now for ex. 32 client-side TTabControl objects handling your clicks on that single tab control in the DOM. OK, so much about the problem. Now, the solution. The bad new is: there isn't a simple one. A complete solution would require to extend TClientScriptManager::registerPostBackControl() (or it's callers) to keeps track of each control's state and only emit the JS code for them if either the current page cycle is an initial full page-load, the control gets replaced in the DOM by a new instance (because for ex. it was on a TActivePanel which got refreshed, or because it was an active control itself which got it's properties modified), or the control is a newly created one which has been constructed in the callback. If none of these are true, it should withhold the code for creating the client-side JS object for the control as there's already one of those at work in the browser. Implementing that will be though to, because of having to keep track of all the updates.

Last 7 days

Last 30 days

Earlier this year