Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    There is no "fix" here, it's correct behavior. See post #12 above.

    Leave a comment:


  • geletkaf
    replied
    Originally posted by Isomorphic View Post
    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

    Leave a comment:


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

    Leave a comment:


  • mpretorian
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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

    Leave a comment:


  • mpretorian
    replied
    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.
    Attached Files

    Leave a comment:


  • mpretorian
    replied
    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:
    Code:
    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.

    Leave a comment:


  • Isomorphic
    replied
    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).

    Leave a comment:


  • mpretorian
    replied
    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?

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • mpretorian
    replied
    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?

    Leave a comment:


  • Isomorphic
    replied
    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?

    Leave a comment:


  • mpretorian
    replied
    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.

    Leave a comment:


  • mpretorian
    replied
    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:

    Code:
    <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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:

Working...
X