As in that case we normally want it to be enabled from the start, as
no selection model is there and so we cannot wait until one item is
selected until we enable it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
while one could use `selModel: null` to achieve this it feels really
weird that `selModel: false` could result in a selection model being
auto searched and set
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in some cases, we provide a config with interval set to 'undefined',
which gets happily applied to the config, but gets interpreted as '0'
when actually starting the task, resulting in constant api requests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This allows to write our often used:
> {
> xtype: me.isCreate ? 'someEditableField' : 'displayfield',
> ...
> }
In a more schematic way, as it can now be controlled by either our
CBind mixin or ExtJS native data binding.
Use a Field container to add both, they editable and they display,
variants of a form field. As default use "textfield" for the editable
and "displayfield" xtype for the read only one.
Pass all but the editConfig and editable members of our initial
config to the display field, allow further to configure the editable
field with an editConfig object, which overwrites the config
properties inherited from the displayConfig/parent config.
This gives full control while not enforcing to specify anything extra
for most default cases.
Enforce initial state of the fields even if the databinding would
handle it to avoid glitches after first render for simple boolean expression
cases.
> {
> xtype: 'pmxDisplayEditField',
> cbind: {
> editable: '{isCreate}',
> },
> name: 'tokenid',
> fieldLabel: gettext('Token ID'),
> value: me.tokenid,
> allowBlank: false,
> }
Here, cbind could also be a bind or a native boolean expression.
For something else than a texfield one would use the editConfig, e.g.:
> {
> ....
> editConfig: {
> xtype: 'pveUserSelector',
> allowBlank: false,
> },
> },
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
when a combobox was editable, a click inside did not open the picker,
but it would if the combobox was not editable.
Since this is
1. Inconsistent
2. Inconvenient (the user has to specifically press the arrow)
we already had this implemented for our ComboGrid, but not for
regular comboboxes
This patch moves the code for this to an override for ComboBox, which
our ComboGrid then inherits (so we do not need it there anymore)
while at it, do some non-significant code-cleanup
* whitespace fixes
* don't shadow 'me' in the focus callback
* fix typo in comment
Originally this was implemented in pve-manager, commit
851c032d69ad5ae23725dd1add9e4084ebc12650
https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=851c032d69ad5ae23725dd1add9e4084ebc12650
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Originally-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this allows to drop setting the default values and ensures that when
interval is updated it actually effects the used update frequency.
Anything which was saved in "me" before, for example me.autoStart, is
still there and gets also updated on a me.setIsStopped(), so there
should be no effects on code using internals.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Used in "Add USB to VM" dialog for example.
This was broken before 15206214d9 "ComboGrid: fix on-load validation for blank
values" (only the one you enabled first was validated, the other always showed
as valid), and afterwards too, but in a different way (both are now immediately
marked invalid until you select and unselect them) - which is how I noticed.
With this the validation now works correctly.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
The three naming schemes are not ideal, but well here we are for now.
Add some hint to explain what one can do with which version - try to
keep it rather short. It's not ideal but hopefully better than
nothing :)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
vlan-raw-device && vlan-id field are only
enabled if interface name is different than interfaceX.Y
I have added a listener on iface,
to enable them live if user want a custom name for vlan interface
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Commit f32aa3df74 fixed marking multi-select fields with where the store
did not contain a valid value after loading.
However, it introduced a bug for single-select fields where the value
(before the store-load) was explicitly set to be empty (when that should
be invalid because of allowBlank === false).
Fix the logic to correctly detect all scenarios (with def being the
value selected before the store loaded, i.e. undefined or an empty
array):
!allowBlank &&
( def is an array but empty || def is not an array and falsy )
Also use correct error message (localized by ExtJS itself).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
can often ve useful and doesn't hurts, somewhat similar to ExtJS
forumlas in viemodels, but inline.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Else we can fail at the first fallback check in getConfigValue while
we still have the possibility to have the cbinded key available in
"me" (initial config).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
when the host has ifupdown2 installed, we can hot apply the config
add a button to do this
if the user does not meet the requirements, the api call
will show why and throw an error (without changing anything)
the button has to be enabled via 'showApplyBtn', because for now,
we do not want it for pmg
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in fields with 'multiSelect: true', we get an array as value instead
of a string, but a check of !![] results in true (since an array
is an object), so we have to explicitely check for arraylength
in 'setValue' (for correctly showing the trigger) and in the
load handler (to not set an empty field wrongfully to invalid)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
on multiSelect we have to check the values that is in the values
array, but we get the 'displaystring' in the validator so we
have to get the 'real' value (aka the underlying array of values)
before checking if they are in the store
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Prevent the comboBox from displaying a validation error although
forceSelection is true. If you change a valid selection by removing
characters manually and click somewhere else, the comboBox restores
the selection with the previous value. The validation logic then
checked the restored value, but couldn't find it in the store,
because the store is still filtered with the erroneous query.
We now clear the local filter before the actual check to prevent
this.
[Thomas]:
This was fixed in the 6.2 based GPL release of ExtJS, and can be seen
as backport.
Signed-off-by: Tim Marx <t.marx@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
