DatasourceField set to hidden="true" does not get set in DynamicForm

[chris@umed.io]

We want to use the DynamicForm functionality of getting the field defintiions from the datasource but it seems that it does not work if a datasourcefuield is set to hidden="true".
I tried it in this showcase example:
https://www.smartclient.com/smartcli...id=screenReuse

I set the "countryCode" in the countryDs to hidden="true" and then used <formID>.getField('countryCode') and it comes up null.
Removing the hidden attrobute and it owrks fine.
The documentation here:
https://www.smartclient.com/smartcli...ataSourceField
... seems to indicate that this should work but perhaps I am missing something.

Can anyone provide some insight as to how I can achieve getting a "hidden" datasourcefield to appear in a DynamicForm withoput having to explicitly specify the field in the DynamicForm please?

[Isomorphic]

The docs explicitly tell you that this is what hidden=true" does.

You haven't explained what you expect hidden="true" to do, since when it hides the field, you don't seem to like that (?), but you might look at DataSourceField.detail, which makes a field appear in forms and other detailed views (like DetailViewer), but not in grids.

[chris@umed.io]

Sorry if I was not clear but the problem is that the field is not in the DynamicForm at all if it is marked as hidden in the DataSource.
The statement in the docs says "..hidden from users" which does not seem to indicate not accessible in the form.
I am expecting the fie;ld to still be rendered into the form but as a hidden field.
So yes, I understand that it will be hidden but I should still be able to access that hidden field in the form.
As stated in the initial post, if I try to access the field marked as hidden in datasource using the form lookup it is not there (as in I get "null" when using the field lookup) .

If I put this in in a DynamicForm:
<field name="myHiddenField" type="text" hidden="true"/>
Then I am able to access it using :
<formID>.getField('myHiddenField')

However, if I leave the DyamicForm empty (ie no fields) and the DynamicForm.dataSource has <field name="myHiddenField" type="text" hidden="true"/> ... along with a bunch of other fields that do NOT have hidden="true" then only the ones that are NOT hidden="true" are accessible in the form using:
<formID>.getField('<someFieldNameFormDatasourceFields>')

[Isomorphic]

What would be the point of creating a HiddenItem?

Are you aware that without an item, the value is still tracked, still accessible and modifiable (form.getValue() / setValue()), still saved when saveData is called, etc?

Just about the only effect of having a HiddenItem would be that if you are doing a native form submit (ie what HTML does when you submit()), it causes the value to be present. For that very rare case (which is basically a deprecated approach used only for legacy systems), you can create the HiddenItem explicitly.

[chris@umed.io]

Thanks for the response.
I am aware that hidden fields will be submitted to the backend (no different to the hidden field that is the primary key for a record).
We use hidden fields for controlling behaviour in the UI on a per record basis (part of what we consider to be a modern UI that is adaptive).
The hidden field determines how certain workflows in the UI behave based on how the user has configured the record when it was created.
I am not sure why having hidden fields is considered a legacy system - perhaps you could point me to documentation that defines why this is now considered legacy design and what the SmartClient suggested mechanism is for supporting fields that are part of a record but not desirable to be shown to the user.
From my perspective, hidden fields are a key tool for a variety of stuff and given that the primary key is always (in modern systems) a hidden field I am at a loss as to what you mean by hidden fields being a legacy thing.

All the above aside, can you confirm if using hidden="true" in the datasource is intended to prevent the field from being added to the DynamicForm or is it a bug that might be fixed by a next release?

[Isomorphic]

We have just explained that a hidden field still supports all of the relevant actions on data.

We have also explained what a hidden field could be used for - a legacy use case:

Just about the only effect of having a HiddenItem would be that if you are doing a native form submit (ie what HTML does when you submit()), it causes the value to be present. For that very rare case (which is basically a deprecated approach used only for legacy systems), you can create the HiddenItem explicitly.

No, there is no plan to change the already-correct behavior regarding hidden fields.

If you don’t understand how to do something, we would suggest that you ask how to achieve your use case, as you seem to be saying that the framework makes something difficult, when in reality, it doesn’t.

[chris@umed.io]

The use case is quite simple actually.
If a field is marked is "hidden" in the datasource , it does NOT get set into the DynmicForm that uses that datasource.

So basically because using a hidden field in a datasource prevents the field from being added in the Dynamic form, the reuse pattern that is such a desirable effect of the DynamicForm is lost.
For some odd reason you are hung up on the idea that I am trying to do something strange.
All I want to do is use the reusable feature of a Dynamicform and it seems you believe that hidden fields in the datasource should not render into the DynamicForm.

The logic you apply seems odd buut so be it -hidden fields in datasources are not reusable objects in the context pof DynamicaForms

[Isomorphic]

Yes, it's definitely strange, since no one else has ever expected there to be a HiddenItem for a "hidden" field - in 20 years :)

So again, what we're asking is: what method did you want to call on HiddenItem, or what function did you expect it to perform for you?

Other than a native form submission, HiddenItem is not known to have any functions that aren't already available on the form. That's why it is basically useless to include, and it would slightly slow things down, in terms of both number of objects created and the size of the DOM.