Summary: | [Chameleon] support for handling widgets in multiple forms | ||
---|---|---|---|
Product: | Chameleon | Reporter: | Daniel Morissette <dmorissette@mapgears.com> |
Component: | Widget | Assignee: | Sacha Fournier <sfournier@dmsolutions.ca> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chameleon-dev@lists.maptools.org |
Priority: | P2 | ||
Version: | 1.1 | ||
Target Milestone: | 1.99 beta 4 | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 92 | ||
Attachments: |
template file with two forms
sample application that calls template with two forms (sample.tar.gz) application that load the two forms template sample_basic_form.zip-Template and application with two forms |
Implemented. The widgets HIDDEN form variables now belong to a form. By default for "0" will be used to put HIDDEN form vars. If you want HIDDEN var from a specific widget to be in an other form, use "FormIndex" widget parameter (0 default).
This bug needs to be verified, but not sure what I am verifying can someone either tell me how to verify or verify it for me. Thanks Changed target for beta 2
Sacha added an attribute to all widgets called FORMINDEX that can be set to an integer value that is the form that the widget is part of. To verify this would require that a new template be created with two forms on it and with widgets in the second form, then set the FORMINDEX of the widget to be 1. This could theoretically be done in one of the samples by adding <form></form> at the beginning of the body before the first form, then putting FORMINDEX="1" into each widget in the form tags (select from <form> to </form> then do search as replace on '<cwc2' with '<cwc2 formindex="1"' within the selection) And the app should function normally.
Created an attachment (id=31) [details]
template file with two forms
Created an attachment (id=32) [details]
sample application that calls template with two forms
Created an attachment (id=33) [details]
application that load the two forms template
I created a template named "sample_basic_form.html" and an application named "sample_basic_form.phtml" based on comment number 3. It is not possible to switch from tab to tab. Also "ZoomIn", "ZoomOut", "Recenter" and "Query" fonctionalities are not working as expected. I attached my template and my application to this bug.
problem caused by many widgets not calling the base class InitDefaults function from their own InitDefaults function. Fixed by examining every widget and adding parent::InitDefaults(); as the first line of the InitDefaults function if used. Also, added check in the core framework to make sure that InitDefaults is called by every widget in the page. Now, if a widget is missing this, an error message will be generated and reported through the error manager and in the HTML template. The
note that the tabs in the example apps won't work correctly because the use of document.forms[0] is hard-coded into the examples. This is not a chameleon error.
verified using the attached templates and by changing a couple widgets formindex="1" to "0" parameter. Viewing the source you can see two separate <form></form> sections. This was verified using beta 2 2004-07-09 on Windows.
Created an attachment (id=40) [details]
sample_basic_form.zip-Template and application with two forms
All widgets are displayed as expected but navigation tools need to be activated each time before being used. Steps to reproduce: 1. Load "sample_basic_form.phtml" application. 2. Click on "ZoomIn" button. 3. Click on the map preview. 4. View is updated as expected (larger scale but "ZoomIn" button is no more selected. Fedora Core 2 Chameleon 20040709
Changed target to 1.99 Beta 3.
tested ... this works fine for me, the problem is that the page contains other javascript to initialize the tabs that that is referring to form[0] (which is invalid) so javascript processing is terminated during page load and the button initialization never happens. There's not much that we can do if the user has invalid javascript on the page.
I was working on something similar when I was this bug resurface ... I just verified comment 14 ... I changed the refernces to forms[0] to forms[1] in the sample.js and everything works as expected (with no javascript errors).
Correction to most recent comment .. "I was working on something similar when I was this bug..." I personally was never this bug - I only saw it.
Changed target for verification to 1.99 RC 1.
In bug 92, Paul listed the following as a TODO item before the 1.1 release: * Sacha to implement support for handling widgets in multiple forms