Opened 9 years ago
Last modified 9 years ago
#9574 new feature
Added programatically preventing resize (start callback returns false)
Reported by: | FrozenArts | Owned by: | FrozenArts |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.resizable | Version: | 1.10.3 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Added programatically preventing resize. For example, if i need to check some condition before grant access to resize <pre> $("#resizable").resizable({
handles: 'e',
start: function (event, ui) {
if (condition) {
return false;
} other logic
}
}); </pre> For example, i can't correctly check if area is locked, and before resing i do some logic, and check if area locked, and then do other logic, but if area is locked - i need to use <pre> return false; </pre> Next option can be used <pre> $("#resizable").resizable("option", "disable" true) </pre> in case of very big portion of dynamic situations.
Pull Request: #1089
Change History (9)
comment:2 follow-up: 3 Changed 9 years ago by
Owner: | set to FrozenArts |
---|---|
Status: | new → pending |
You haven't actually provided a use case. You've just provided a sample implementation using a boolean. It's also not clear why you can't use the disabled option, which you've already said that you can use.
comment:3 Changed 9 years ago by
Status: | pending → new |
---|
Replying to scott.gonzalez:
You haven't actually provided a use case. You've just provided a sample implementation using a boolean. It's also not clear why you can't use the disabled option, which you've already said that you can use.
I have many resizable objects, like a grid. When user iteracts with one resizable module, other blocks could be static and not resizable, and i need in start event check, is user can resize that block. It means generic calculation before resize.
Does it make sense?
comment:4 follow-up: 5 Changed 9 years ago by
I feel like this should be handled differently. If a block is resizable, make it resizable and if it's not, don't. Then the user can see which blocks are resizable and which aren't making a better user experience. As a user, I would be annoyed by something looking resizable but not allowing me to resize it.
comment:5 Changed 9 years ago by
Replying to k_borchers:
I feel like this should be handled differently. If a block is resizable, make it resizable and if it's not, don't. Then the user can see which blocks are resizable and which aren't making a better user experience. As a user, I would be annoyed by something looking resizable but not allowing me to resize it.
Sometimes we need to check if user can resize this block, and dynamically block it before start, but, in case of disabling resize by use of disable option, i need to verify a big portion of data before disable in each module, but if i can disable from start, i can check special model flag and disable the resizable. This case very usefull
comment:7 follow-up: 8 Changed 9 years ago by
Not against master. No API changes are allowed for any interaction plugin until the rewrite lands. The rewrite for resizable has not begun.
comment:8 follow-up: 9 Changed 9 years ago by
Replying to scott.gonzalez:
Not against master. No API changes are allowed for any interaction plugin until the rewrite lands. The rewrite for resizable has not begun.
I have a code, with small changes just. Also, does resizable will be rewritten?
comment:9 Changed 9 years ago by
Replying to FrozenArts:
I have a code, with small changes just.
It doesn't matter how small the code is; API changes will not be accepted right now.
Also, does resizable will be rewritten?
Yes, as I said above.
Added programatically preventing resize. For example, if i need to check some condition before grant access to resize http://jsfiddle.net/EDyB4/
For example, i can't correctly check if area is locked, and before resing i do some logic, and check if area locked, and then do other logic, but if area is locked - i need to use
Next option can't be used
in case of very big portion of dynamic situations.