Comboboxes not working in 3.x Beta

[gsaxena]

Hi,

I believe there's a bug with today's beta realase of SmartGWT EE 3.0. If you look at the attached screenshot, you'll see that the drop-down arrow for the selectItem combobox is disabled for 3 out of the 5 comboboxes. We're not sure why 3 of them are disabled but the other 2 work fine. The reason why we're fairly sure it's a bug is that when we use an OLDER version of SmartGWT 3.x (release date of September 26, 2011), all selectItem comboboxes appear normally. Our SmartGWT code in both cases is 100% identical.

As well, and we're not sure if this is related, we get the warning message in the "SmartClient Developer Console":

09:35:20.466:MUP7:WARN:PickListMenu:isc_PickListMenu_0:fields and completeFields are null and there is no DataSource
09:35:20.502:MUP7:WARN:PickListMenu:isc_PickListMenu_1:fields and completeFields are null and there is no DataSource

However, we get this warning message even with the OLD SmartGWT 3.x (ie from September 26, 2011), and the combo boxes DO work in that situation. (You can see this warning message in the 2nd attached screenshot as well.)

Is there anything we should do (ie hack) to get the comboboxes to work in latest 3.0 release or should we just wait for the fix?

Additional infracstructure details are below:
==================================================

OS: Windows XP Pro
IDE: MyEclipse 9.0 with Google Plugin for Eclipse (2.3.1)
SmartGWT EE 3.0 (Release of November 01, 2011, ie latest)
Browwer: Mozilla Firefox 4.0.1
GWT SDK: 2.3
Sun JDK 1.6.0_27

[Isomorphic]

You need to post a minimal standalone test case, not screenshots. The fact that your application broke doesn't give us the ability to reproduce the problem, and could be either a sign of a bug or just bad usage that is now being correctly detected.

[mpretorian]

I have the same problem.

With smartgwt-power-edition-3.0.2011-11-10 and 3.0.2011-10-26 the comboboxes are disabled but with the version from 3.0.2011-09-25 are enabled.
I use Firefox-3.6/Tomcat-7 / Development/production mode, GWT-2.4.

Our usecase is a dynamic form with a SelectItem that is bound to a field in a datasource defined like here:

<field name="fieldName" type="text" optionDataSource="fieldOptionDs"
	displayField="fieldName" valueField="fieldName" length="20"
	allowEmptyValue="true" sortField="fieldName" 
	nativeName="field_column" tableName="field_table"
	operator="inSet" />

While searching for the reason why the item is disabled I have seen that the browser fetches correctly the data from the option datasource using a DSRequest with "componentId":"isc_PickListMenu_1", but the DevConsole shows that the isc_PickListMenu_1 object is not drawn and is placed on the position 0,0 with a Drawn Size of 146w x 1h.

I also have other comboxes that don't suffer from this issues. While comparing their field definitions I noticed that they don't have the "tableName" attribute. So I remove it from the problematic field definition and the combobox was enabled again.

[mpretorian]

I tested again with the older version 3.0.2011-09-25 and I see that the isc_PickListMenu_1 object that makes the fetch to the option datasource is now drawn right below the combobox and has additionally a GridBody that was present in the latest version.

[Isomorphic]

We've mentioned before that it's a hack with unpredictable effects to put optionDataSource properties into a .ds.xml file, where they are not documented as valid. Can you let us know if this is reproducible for you with valid usage?

[mpretorian]

Could you please tell me what properties are not documented as valid in the field definition mentioned by me?

These are the properties meant for the datasource that includes that field:
name="fieldName"
type="text"
length="20"
allowEmptyValue="true"
nativeName="field_column"
tableName="field_table"
operator="inSet"

and these one are meant for the relation with the optionDataSource:
optionDataSource="fieldOptionDs"
displayField="fieldName"
valueField="fieldName"
sortField="fieldName"

Is one of them wrong or not documented as valid?

[Isomorphic]

Docs are right here. Again, several of those properties, critically optionDataSource, are not documented for DataSourceField. They are documented on component fields and have component-specific behaviors.

[mpretorian]

1. Was this issue recognized as a bug? If yes, was the bug fixed?

2. If it is not recognized as a bug could you recommend a clear solution?

3. Is moving the optionDataSource related attributes from the field definition to the UI component the solution you would recommend?

[Isomorphic]

This is a bit confusing - once again, invalid usage is not considered a bug, but if you can show a test case where valid usage leads to a problem, that would be considered a bug.

And yes, valid usage means moving the attributes out of the DataSource (where they are not documented as valid) and onto a UI component (where they are documented).

[mpretorian]

Hi,
I tested again this problem with the version 3.0.2011-12-16. The same behavior.
Then I removed the attributes from the xml field definition that are not documented here: http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/serverds/DataSourceField.html#tableName
The field contained only these attributes:

name="fieldName"
type="text"
length="20"
nativeName="field_column"
tableName="field_table"

But I still got the same problem. The field was still disabled.

Then I removed the tableName="field_table" attribute and the field got enabled, but of course the query didn't work anymore well.

[mpretorian]

I added a modified example from the showcase. See the attached pictures and java file. They show that the itemName field that has the attribute tableName is displayed disabled in the dynamic form.
I removed that attribute and it was displayed enabled.
Please tell me if this is a bug, and if yes when can be solved.
We cannot use the new version of the library because of this problem.

[Isomorphic]

Fields in a dataSource which have a specified tableName are (typically) populated by a database join. Such fields not truly editable by default in that custom server code is required to actually update the database tables correctly.

As such we've made a change to the framework to mark fields with a specified tableName as canEdit:false by default.
There are a couple of ways to change this behavior in your application:

- When putting together filter criteria, such fields should of course be user-editable. This is already handled if you use a SearchForm rather than a DynamicForm as your component. Search forms are also configured with some other behaviors which make more sense for generating criteria -- for example showing a date range item for editing date fields.

- If you actually do have custom server logic to save out an edit to a field with a specified tableName, or a SearchForm is inapplicable in your usage for some other reason you can explicitly set "canEdit" to true on the field in order to have it be editable.

We're also curious as to how you hit this situation. Are you editing criteria or do you have custom server logic to handle saving edits to a field with a specified tableName?

Regards
Isomorphic Software

[mpretorian]

We hit the problem while using a datasource only for fetch operation, where some fields from the search form are mapped to columns from a joined table.
Btw, I tested your proposals.
- Setting the canEdit attribute on the fields makes those previously disabled fields now editable in the dynamic form.
- But changing from Dynamic form to SearchForm didn't solve the problem. The fields are still disabled.
I did the tests using the latest version 3.0.2012-01-09.

[Isomorphic]

Ok we see that problem with SearchForms disallowing editing of these fields. We'll have this fixed in the next nightly build

[geletkaf]

Ok we see that problem with SearchForms disallowing editing of these fields. We'll have this fixed in the next nightly build

Hi.
Did you at the end fix this problem with not disabling items in DynamicForm which are bind to the DataSourceField with defined atrribute tableName ? I am asking, because I tested again showcase from this post http://forums.smartclient.com/showpost.php?p=78486&postcount=11 and I can still reproduce this issue.
Thanks