Is it correct that a filter editor uses the field's default value as initial value?

[wallytax]

I have a grid with a filter editor (showFilterEditor: true). The grid contains a field that has a defaultValue in the data source. I see that this default value is used to populate the filter above the field. In the initial fetch (triggered by autoFetchData: true), this default value is not sent to the server, but it is when I call grid.refreshData().

In my opinion should the default value not be used in the filter.

I've tried setting grid.initialCriteria: { <field>: null } but this doesn't seem to work either.

[Isomorphic]

defaultValue is not a valid property on DataSourceField (see docs). It's only valid in other contexts, such as FormItems.

This is no supported away around this problem other than correcting your property usage. Note that if you found something that seemed to work, that hack would be likely to just break later.

[wallytax]

Setting the "defaultValue" property in the data source, made working with editing in grids and/or forms easier, because it only required me to place the default value in one place (my RubyOnRails model from which a data source class is created). DynamicForm and ListGrid use the default value from the data source, but now it turns out this is not the preferred way. What is then the preferred way? Telling my RubyOnRails model what the default value is and in every SmartClient component where I want to edit the record write that same default value again? So if I ever want to change the default value, I need to change it in 2 or more locations?

[Isomorphic]

DataSource are used to generate interfaces for both editing (like DynamicForm) and for filtering (like filterEditor, SearchForm and FilterBuilder).

Obviously, these two scenarios (editing vs searching) would have different default values. That's why you can't just configure it at the DataSource level - it's not some arbitrary rule we made up, it just doesn't make sense.

This is before even considering that it's very common for different edit forms to have different default values in different circumstances, for different users, etc.

If a universal default value makes sense somehow in your app, a common way to do this would be to:

1. create a subclass of DynamicForm that you use everywhere
2. have that subclass establish default values for fields based on a custom DataSource property

Be sure to use a non-colliding name for any custom DataSource property. For example, this might be "wtDefaultEditValue".

[wallytax]

Before starting this thread I've discussed this default value behavior with a colleague (not how it should technically work, but what one would expect functionally) and our conclusion was that the default value we use in the database would be a good default value for the form, but not when searching for data.

I think that when you write "it's not some arbitrary rule we made up, it just doesn't make sense." you are expressing your opinion, which of course you have all right to do. I have a different opinion (at the moment). And since you build the framework I have to redesign my code and the suggestion you make is a good one. :-) The only thing that would then be quite hard is how to set the default value for all fields of the form programmatically, since fields are objects, but I'll be able to do that.

The way "my brain" is working, is that I have a default value in a Ruby model. From it, I can create a database migration script with that same default value as column default. That same default can be used in most forms and in situations where it needs to differ, I would use another "defaultValue" property inside that form's field definition. If I know beforehand that the model's default is not "so default", I would not have defined a default value in my Ruby model at all.

Again, arguing about this is probably a waste of time, but I just wanted to give you another point of view.

Your suggestion is useful however and I understand it. Please don't feel offended by my opinion. Maybe it's just my opinion. - therefore it would be nice if others would like to react - or maybe it's a "cultural" thing (Europe / US). I don't know. Knowing the limitations and/or possibilities of the framework is a matter of time I guess. And maybe some of my suggestions are beneficial for the framework. I leave that up to you.

[Isomorphic]

Again, DataSources are used to configure both components that are used for editing, and components that are used for search.

So there can't be just a single property that configures defaultValue in the DataSource. It would produce exactly the nonsense result you got: a default value intended for editing appears in search forms.

This isn't an opinion, it's just a fact.

It, of course, would be possible to enhance the framework so that there were multiple properties on DataSourceField, one to configure a default value for editing, and separately, one to configure a default value for search.

We might add that at some point, and we have already guided you to a simple way to achieve this in your application, even without a framework feature that does this.

[wallytax]

An extra option might be a good idea. For now, I will fix my code. Thanks for taking the time to write these answers.