You need to log in before you can comment on or make changes to this bug.
We have run many times (way too many times) with clients using chameleon into issues related to case-sensitivity of FORM parameters. There have already been several hours wasted on case-sensitivity issues and this is going to be a main issue for chameleon if we don't do something about this now. I realize that PHP's $_GET and $_POST arrays are case-sensitive, but the chameleon engine tries to offer a more user-friendly interface for beginners (non-programmers) and shouldn't be case-sensitive when accessing form parmaters. So what I propose is that: 1- In the Chameleon initialization, the $_GET + $_POST arrays are scanned and all keys in the array are made *lowercase* (I know you use uppercase almost everywhere, but that's another issue that we can fix at the same time since it seems that lowercase is the way HTML and XML are going, so Chameleon should follow that trend too since it relies on those heavily.) 2- All code accessing FORM parameters in chameleon should use the parameter name in lowercase, or use some method that takes care of the cases abstraction (Sacha tells me that there is a get() method somewhere that could do that but that is barely used anywhere) 3- All documentation on widgets and on chameleon should refer to widget parameters and form parameters as lowercase. I think this was already agreed to in previous discussions for the widget parameters docs, but the same should be extended to form parameters docs. Comments, flames welcome.
yes, I am all for things being lowercase. lowercase is definitely the future as daniel points out, xhtml requires that all takes be lowercase. i don't like to look at source code that yells. ;-)
As far as I am aware, everything is explicitly converted to uppercase now, everything in Chameleon was designed to expect uppercase internally but to accept any case coming in. I can think of a couple of exceptions, of course, but they should be considered bugs or improper implementation. This is not required, just a choice that was made to simplify the code (less case-specific exceptions). The rationale is not strong, except that it seems to me that a lot of tools (used to) generate tag names and parameters in uppercase, and stuff in uppercase is more obvious. I doubt picking lowercase will change anything, except cause more work and potentially more bugs in existing code while trying to convert it. Everything either has to be explicitly converted or have multiple case-specific checks. There is a getvalue method in widget that was intended for this purpose, it went out of favour when I tried to do some optimizing. Accessing values directly instead of through a function call resulted some fairly significant savings. Removing the getvalue code resulted in the uppercase convention. I would be interested in the details of any bugs that resulted in this discussion. Perhaps Sacha/Julien can provide details? I am hesitant to make this change without a better understanding of the issues.
We can't give explicit examples of the problems here since they are client specific examples, but the issue is that several widgets developed recently have problems with case sensitivity of form parameters and this has caused at least a dozen bugs and lots of frustrations since we started deploying chameleon stuff. I'm glad to hear that form parameters are already case-insensitive in chameleon, that reduces the extents of the problem to fixing only those widgets that are currently in trouble, right? ;) Sacha should probably discuss the way to handle this in more details with you tomorrow. About the lowercase vs uppercase question, I can live with the use of uppercase internally as long as it's not mixed cases (I would have picked lowercase if we were to start this over again but let's keep uppercase if everything is already done this way).
Um... I did a quick test and it seems that chameleon is indeed case-sensitive when reading form parameters (so I misinterpreted comment#2 above). I modified the hawaii demo to use the GET method and changed the NAV_CMD parameter to nav_cmd and its value was ignored. So perhaps the intention in chameleon was "to accept any case coming in", but that's not happening everywhere for sure and my complain/request for case-insensitive form parameter names remains. Note that if the $_GET + $_POST arrays were scanned once at the beginning of script execution to make all parameter names uppercase then you would not need to use getvalue() and there wouldn't be much (if any) hit on performance related to this change.
just to follow up on this. I was mistaken, it is not the form parameters that are explicitly upper case, it is all the widget attributes. The form parameters are left in whatever state the widget or user put them in. I believe from the discussions that I had with Sacha and Daniel that the problem was with the session id provided by PHP, it is placed in the form with a lower case name (sid), whereas the _convention_ has been to use uppercase form names in the widgets. I think at least one widget does not use this convention (Language) but that should be considered a bug, as should other cases of the same thing. This can be fairly easily confirmed by scanning the source code. However, I am not convinced that we need to uppercase all incoming form variables. This could, in my mind, add some confusion since a chameleon application consists of both widgets and user code. I think that it could be quite likely that the user would use form values for his/her own purposes outside of Chameleon, and would be perhaps confused if they ended up as uppercase all the time. It could be a documentation issue. I would prefer that it just be a convention in CWC coding style. Not sure what to do with this, though. More comments/feedback would help.
I dunno what else to suggest for the way to handle this internally, but I still think it's important to be case-insensitive or to force the use of a given convention (uppercase or lowercase) *everywhere* in Chameleon. Either way, whether we just document the requirement to use uppercase everywhere, or whether we include code in Chameleon to make all form inputs uppercase internally, Chameleon developers and users will end up being forced to use all lowercase or all uppercase if we want to avoid confusion down the road. i.e. just documenting the issue doesn't make things simpler for the users anyway and you lose the benefit of the case-insensitivity that is added by a software solution where you add code to convert all inputs to be uppercase internally.
My thoughts: When applying a GET or POST in a CGI, servlet, etc., it is common practic to allows case-insensitive form keywords, and case-sensitive form values. i.e. the two requests should be processed identically: http://atlas.gc.ca/cgi-bin/atlaswms_en?VERSION=1.1.0&REQUEST=GetCapabilities http://atlas.gc.ca/cgi-bin/atlaswms_en?version=1.0.0&request=GetCapabilities How this gets processed on the inside is another issue. But clients constructing URLs should expect case-insensitive form keywords to work. As an example, note that all OGC specifications apply this approach to their numerous web service implementation specifications.
there is a an HtmlFormVars object that handles stuff case-insensitively but it does add overhead which is an issue. There is a new function in php (ver >= 4.2.0) called array_change_key_case that can be used to upper/lower case all array keys, I would imagine this is the cheapest way to do it. The one problem that still remains for most stuff is that the session id is sometimes assumed to be 'sid' (lowercase) and any code that assumes this will have to be identified and fixed. This should be rooted out for 1.99.
updated version to 1.99
looking at this now. This could involve modification to every single widget to make it work but I will try to limit the changes as much as possible. Currently form variables are accessed through two separate mechanisms: 1. each widget has a member variable called moURLArray which is a pointer to either $_GET or $_POST. 2. there is an instance of the HttpFormVars class in the global Chameleon application object that can be used to get at values case-insensitively. Highest performance will be gained by using the array, but more flexibility will be gained by switching all widgets to use HttpFormVars as well as case insensitivity. If we agree on the change then I will add a new member variable to Widget called moURLObject and it will be a pointer to the HttpFormVars instance kept in the global Chameleon app. Then I will go through all widgets :( to replace references to moURLArray to moURLObject. Finally, I will remove moURLARray from Widget so any further code that is developed will generate errors. Then I will work on optimizing HttpFormVars for performance by forcing all the array keys to uppercase and then using an uppercase version of the requested key to find values. Comments and suggestions welcome.
since there are no objections, this is now done. Three new functions have been added to the base Widget class, isVarSet( $szVarName ) getVar( $szVarName ) setVar( $szVarName, $szValue ) and all access of the moURLArray array has been converted to use these three functions. These functions act on a single instance of HttpFormVars managed by the application instance. The moURLArray still exists and works in the same way that it used to, but it is deprecated and will be removed in the next version. Please update your code accordingly. All new code must use the new functions.
I believe this is verified using beta 2 2004-06-20, windows ie 6, by editing template parameters and widgets to different cases. If anyone things there is a better way of verifying this let me or norm know. This could be a common test applied to new widgets.
The tests to verify the were insuficient, the QA team need some suggestions on how this can be verified.
Daniel, could you provide us with a methodology to test that this bug is fixed?
I would think that what Chris wrote that he did in comment #12 is the way to go, assuming he tested both widgets and form parameters... unless you want to spend weeks testing all possible widgets and form parameters individually (or developing a tool to do that). I think you'll have to trust your small set of tests and Paul's word on this one.
I verified using the test methodology used in comment #4 on Fedora Core 1. ------------------ Just a note as a reminder of the expected test result: Modifying spelling of form element: might cause an error or change map displayed. Modifying case of form element: should not output any error and change map displayed.
