Added programatically preventing resize (start callback returns false)

[FrozenArts]

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

[FrozenArts]

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

 return false;

Next option can't be used

$("#resizable").resizable("option", "disable" true)

in case of very big portion of dynamic situations.

[Scott González]

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.

[FrozenArts]

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?

[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.

[FrozenArts]

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

[FrozenArts]

Can i create a pull request with source code changes?

[Scott González]

Not against master. No API changes are allowed for any interaction plugin until the rewrite lands. The rewrite for resizable has not begun.

[FrozenArts]

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?

[Scott González]

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.