Re: [jQuery] Interface: draggables, droppables, and sortables
Stefan, I hate to harp on this, but the more I work with your new draggables automatically become sortables function, the less i like it. While the demo you created certainly works, I have a couple of issues with it. First, from a usability perspective, I would want to turn ghosting on for the items in the pallette; doing that currently breaks the demo. Right now, if a user drags an item in the pallette, it appears as if it's being removed, not cloned. I'm sure this will be fixed eventually. Secondly, your code change more or less makes droppables obsolete, and unless your objective is to do exactly what Brendan had set out to do, it's unintuitive logic. If I have something I want to drag, I would also have something to drop it on. Converting it into a sortable object is not the most likely use case scenario. Instead, wouldn't the SortableAddItem function be the more logical solution? I don't want to give the impression that I'm not grateful for your contributions - I AM! I just think that you reacted so quickly to one person's feature request and may not have considered what it meant in the bigger picture for everyone else. bbuchs wrote: Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are essentially a palette of items. The user should be dragging out a copy of each item, not the item itself. Again, that can be accounted for if the ghosting bug is fixed. Thanks guys! - Bryan Brendan O'Brien wrote: Hi, I'm responding to a few things in this post. First, I took a look at Bryan's example pages. The problem you see on the second page (where isortables.js has been included, but no Sortables have been declared) that throws the error |jQuery.iSort.helper.get is not a function|; I've had this problem too even before the Sep. 11 patch. The problem is that when isortables has been included, then draggables attempts to execute the line: jQuery.iSort.helper.get(0).style.display = 'none' when dragging over a droppable to hide the sortable helper. But since you never called Sortables this variable is just the boolean value false. It only gets initialized when something is made Sortable. That's why on your third page, where you make something Sortable, that problem doesn't occur anymore. I think this is probably just a bug. Either draggables shouldn't attempt to hide the helper field if it hasn't been initialized (this is easy to do since the value is false by default. I did this on my local build and it seems to work), or including isortables.js should initialize the field even if nothing has been declared as Sortable. Second, thanks Stefan for adding the functionality that allows Sortables to accept draggables even if they didn't originate from a sortable container. This solves the problem I was having. And I really like how I can now drag items from outside the sortable container, and it shows where the item will be dropped. It's great. I do agree with Bryan though that not everyone will want this, so maybe there could be a switch to turn it off? I'm not sure how hard that would be. Anyway, I tried disabling it by just changing the class name of the draggables to something that Sortables doesn't accept, and that works just fine. Hopefully that helps for now. The only problem I have now when working with your demo page (sorry for being nit picky, it's just that my users are picky so I have to be!), is that when I pick up a draggable, it is removed from the other draggables (this also happens on Bryan's third test page). This is fine, it's the default behavior. When I add ghosting : true to the draggable config, it still gets removed. But when I hover over the sortable container it does show a copy of the draggable, instead of the normal empty helper. This is the behavior I would normally expect from adding ghosting : true to the sortable config. But actually, adding ghosting : true to the sortable config doesn't have any effect. Other than that, the new functionality is great! Bryan, I hope the workaround I mentioned for the new stuff helps (I still agree though that a switch to turn it on and off would be nice). Regards, Brendan On 9/16/06, *Stefan Petre*
Re: [jQuery] Interface: draggables, droppables, and sortables
Sorry, but I just had another tought... The demos I initially provided were simplified - my end goal is not to just move an DOM element from one side of the page to another. What I was trying to accomplish was that the dropping would initiate a function that creates a brand new DOM element that is quite different from the one that had been dragged. I suppose I should have made that clearer from the start. - bryan bbuchs wrote: Stefan, I hate to harp on this, but the more I work with your new draggables automatically become sortables function, the less i like it. While the demo you created certainly works, I have a couple of issues with it. First, from a usability perspective, I would want to turn ghosting on for the items in the pallette; doing that currently breaks the demo. Right now, if a user drags an item in the pallette, it appears as if it's being removed, not cloned. I'm sure this will be fixed eventually. Secondly, your code change more or less makes droppables obsolete, and unless your objective is to do exactly what Brendan had set out to do, it's unintuitive logic. If I have something I want to drag, I would also have something to drop it on. Converting it into a sortable object is not the most likely use case scenario. Instead, wouldn't the SortableAddItem function be the more logical solution? I don't want to give the impression that I'm not grateful for your contributions - I AM! I just think that you reacted so quickly to one person's feature request and may not have considered what it meant in the bigger picture for everyone else. bbuchs wrote: Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are essentially a palette of items. The user should be dragging out a copy of each item, not the item itself. Again, that can be accounted for if the ghosting bug is fixed. Thanks guys! - Bryan Brendan O'Brien wrote: Hi, I'm responding to a few things in this post. First, I took a look at Bryan's example pages. The problem you see on the second page (where isortables.js has been included, but no Sortables have been declared) that throws the error |jQuery.iSort.helper.get is not a function|; I've had this problem too even before the Sep. 11 patch. The problem is that when isortables has been included, then draggables attempts to execute the line: jQuery.iSort.helper.get(0).style.display = 'none' when dragging over a droppable to hide the sortable helper. But since you never called Sortables this variable is just the boolean value false. It only gets initialized when something is made Sortable. That's why on your third page, where you make something Sortable, that problem doesn't occur anymore. I think this is probably just a bug. Either draggables shouldn't attempt to hide the helper field if it hasn't been initialized (this is easy to do since the value is false by default. I did this on my local build and it seems to work), or including isortables.js should initialize the field even if nothing has been declared as Sortable. Second, thanks Stefan for adding the functionality that allows Sortables to accept draggables even if they didn't originate from a sortable container. This solves the problem I was having. And I really like how I can now drag items from outside the sortable container, and it shows where the item will be dropped. It's great. I do agree with Bryan though that not everyone will want this, so maybe there could be a switch to turn it off? I'm not sure how hard that would be. Anyway, I tried disabling it by just changing the class name of the draggables to something that Sortables doesn't accept, and that works just fine. Hopefully that helps for now. The only problem I have now when working with your demo page (sorry for being nit picky, it's just that my users are picky so I have to be!), is that when I pick up a draggable, it is removed from the other draggables (this also happens on Bryan's third test page). This is fine, it's the default behavior. When I add ghosting : true to the draggable config, it still gets removed. But when I hover over the sortable container it does show a copy of the draggable, instead
Re: [jQuery] Interface: draggables, droppables, and sortables
Bryan,What you're trying to do is exactly what I want as well. The approach I had was to make the container Droppable and Sortable. But like I said in my original email you can't do this because Sortable hijacks the Droppable functionality. I was just looking for a way to use both on the same container. If there wasn't a good workaround, then I was thinking something like Sortable having its own separate functionality, instead of overwriting the Droppable functionality that you may have already added. So it would still use Droppables, but in its own space, if that makes any sense. Because I don't want it to overwrite the onDrop callback, for example. I was using onDrop to create new elements, just as Bryan described. I see that in Stefan's example he is using the onStop callbacks of Draggable to create the element. I didn't use this originally because it doesn't give you the container that the Draggable was dropped in, but onDrop does. And I need the container. And speaking of the demo, I agree with Bryan that the demo isn't perfect. I also would like to use ghosting to drag from my pallette, but that doesn't really work now. And I also agree that Droppables is obsolete. Which is not good, because like I said I need to use onDrop, not onStop. Anyway, the reason I wrote the original email was to1. Point out that since Sortables hijacks any previously defined Droppables, the two cannot be used together in the same container.2. See if there was a workaround for it. I wasn't necessarily asking for a code change (unless there was no workable solution). So if there is a workaround (without the new change), I'd love to hear it. Bryan, maybe you have some ideas? And if so, maybe we should go back to the original functionality.Thanks,Brendan On 9/21/06, bbuchs [EMAIL PROTECTED] wrote: Sorry, but I just had another tought...The demos I initially provided were simplified - my end goal is not to justmove an DOM element from one side of the page to another. What I was tryingto accomplish was that the dropping would initiate a function that creates a brand new DOM element that is quite different from the one that had beendragged. I suppose I should have made that clearer from the start. - bryanbbuchs wrote: Stefan, I hate to harp on this, but the more I work with your new draggables automatically become sortables function, the less i like it. While the demo you created certainly works, I have a couple of issues with it. First, from a usability perspective, I would want to turn ghosting on for the items in the pallette; doing that currently breaks the demo. Right now, if a user drags an item in the pallette, it appears as if it's being removed, not cloned. I'm sure this will be fixed eventually. Secondly, your code change more or less makes droppables obsolete, and unless your objective is to do exactly what Brendan had set out to do, it's unintuitive logic. If I have something I want to drag, I would also have something to drop it on. Converting it into a sortable object is not the most likely use case scenario. Instead, wouldn't the SortableAddItem function be the more logical solution? I don't want to give the impression that I'm not grateful for your contributions - I AM! I just think that you reacted so quickly to one person's feature request and may not have considered what it meant in the bigger picture for everyone else. bbuchs wrote: Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are essentially a palette of items. The user should be dragging out a copy of each item, not the item itself. Again, that can be accounted for if the ghosting bug is fixed. Thanks guys! - Bryan Brendan O'Brien wrote: Hi, I'm responding to a few things in this post. First, I took a look at Bryan's example pages.The problem you see on the second page (where isortables.js has been included, but no Sortables have been declared) that throws the error |jQuery.iSort.helper.get is not a function|; I've had this problem too even before the Sep. 11 patch.The problem is that when isortables has been included, then draggables attempts to execute the line: jQuery.iSort.helper.get(0).style.display = 'none' when dragging over a droppable to hide the sortable helper.But since you never called Sortables this variable is just the boolean value false.It
Re: [jQuery] Interface: draggables, droppables, and sortables
Stefan (I hope you're listening in!) Brendan and I have been trading messages about this off-list, and came to the same conclusion: Please roll back the code to the old sortables draggables methods Although the methods you added to insert draggables into any sortables is neat, it lacks the powerful callback abilities that the original drag/drop/sort functions had. And since it would be possible to replicate the draggablesortable functions using those original callback methods, it seems to make sense to go back. Please feel free to contact me directly if you'd like to disucss off-list. -- Bryan Buchs [EMAIL PROTECTED] Brendan O wrote: Bryan, What you're trying to do is exactly what I want as well. The approach I had was to make the container Droppable and Sortable. But like I said in my original email you can't do this because Sortable hijacks the Droppable functionality. I was just looking for a way to use both on the same container. If there wasn't a good workaround, then I was thinking something like Sortable having its own separate functionality, instead of overwriting the Droppable functionality that you may have already added. So it would still use Droppables, but in its own space, if that makes any sense. Because I don't want it to overwrite the onDrop callback, for example. I was using onDrop to create new elements, just as Bryan described. I see that in Stefan's example he is using the onStop callbacks of Draggable to create the element. I didn't use this originally because it doesn't give you the container that the Draggable was dropped in, but onDrop does. And I need the container. And speaking of the demo, I agree with Bryan that the demo isn't perfect. I also would like to use ghosting to drag from my pallette, but that doesn't really work now. And I also agree that Droppables is obsolete. Which is not good, because like I said I need to use onDrop, not onStop. Anyway, the reason I wrote the original email was to 1. Point out that since Sortables hijacks any previously defined Droppables, the two cannot be used together in the same container. 2. See if there was a workaround for it. I wasn't necessarily asking for a code change (unless there was no workable solution). So if there is a workaround (without the new change), I'd love to hear it. Bryan, maybe you have some ideas? And if so, maybe we should go back to the original functionality. Thanks, Brendan On 9/21/06, bbuchs [EMAIL PROTECTED] wrote: Sorry, but I just had another tought... The demos I initially provided were simplified - my end goal is not to just move an DOM element from one side of the page to another. What I was trying to accomplish was that the dropping would initiate a function that creates a brand new DOM element that is quite different from the one that had been dragged. I suppose I should have made that clearer from the start. - bryan bbuchs wrote: Stefan, I hate to harp on this, but the more I work with your new draggables automatically become sortables function, the less i like it. While the demo you created certainly works, I have a couple of issues with it. First, from a usability perspective, I would want to turn ghosting on for the items in the pallette; doing that currently breaks the demo. Right now, if a user drags an item in the pallette, it appears as if it's being removed, not cloned. I'm sure this will be fixed eventually. Secondly, your code change more or less makes droppables obsolete, and unless your objective is to do exactly what Brendan had set out to do, it's unintuitive logic. If I have something I want to drag, I would also have something to drop it on. Converting it into a sortable object is not the most likely use case scenario. Instead, wouldn't the SortableAddItem function be the more logical solution? I don't want to give the impression that I'm not grateful for your contributions - I AM! I just think that you reacted so quickly to one person's feature request and may not have considered what it meant in the bigger picture for everyone else. bbuchs wrote: Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are
Re: [jQuery] Interface: draggables, droppables, and sortables
Brendan, Thanks for doing a good job explaining what I was trying to - the jQuery.iSort.helper.get bug. I would hope that this can be fixed. I can see a situation where I might want to have a list on a page that isn't a sortable until a user initiates that action (click here to sort this list). If I have any other draggables on the page, I would get the error described below. Your tip about the accepts paramater also works great. I still strongly disagree that draggables should automatically become part of a sortable if it's dropped in one, but at least I can work around it. The only remaining issue I have is that the draggablesortable feature breaks the ghosting functionality for the draggable. In my demo, the right-side draggables are essentially a palette of items. The user should be dragging out a copy of each item, not the item itself. Again, that can be accounted for if the ghosting bug is fixed. Thanks guys! - Bryan Brendan O'Brien wrote: Hi, I'm responding to a few things in this post. First, I took a look at Bryan's example pages. The problem you see on the second page (where isortables.js has been included, but no Sortables have been declared) that throws the error |jQuery.iSort.helper.get is not a function|; I've had this problem too even before the Sep. 11 patch. The problem is that when isortables has been included, then draggables attempts to execute the line: jQuery.iSort.helper.get(0).style.display = 'none' when dragging over a droppable to hide the sortable helper. But since you never called Sortables this variable is just the boolean value false. It only gets initialized when something is made Sortable. That's why on your third page, where you make something Sortable, that problem doesn't occur anymore. I think this is probably just a bug. Either draggables shouldn't attempt to hide the helper field if it hasn't been initialized (this is easy to do since the value is false by default. I did this on my local build and it seems to work), or including isortables.js should initialize the field even if nothing has been declared as Sortable. Second, thanks Stefan for adding the functionality that allows Sortables to accept draggables even if they didn't originate from a sortable container. This solves the problem I was having. And I really like how I can now drag items from outside the sortable container, and it shows where the item will be dropped. It's great. I do agree with Bryan though that not everyone will want this, so maybe there could be a switch to turn it off? I'm not sure how hard that would be. Anyway, I tried disabling it by just changing the class name of the draggables to something that Sortables doesn't accept, and that works just fine. Hopefully that helps for now. The only problem I have now when working with your demo page (sorry for being nit picky, it's just that my users are picky so I have to be!), is that when I pick up a draggable, it is removed from the other draggables (this also happens on Bryan's third test page). This is fine, it's the default behavior. When I add ghosting : true to the draggable config, it still gets removed. But when I hover over the sortable container it does show a copy of the draggable, instead of the normal empty helper. This is the behavior I would normally expect from adding ghosting : true to the sortable config. But actually, adding ghosting : true to the sortable config doesn't have any effect. Other than that, the new functionality is great! Bryan, I hope the workaround I mentioned for the new stuff helps (I still agree though that a switch to turn it on and off would be nice). Regards, Brendan On 9/16/06, *Stefan Petre* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, The sortable is composed from draggables and droppables, this way I reused code. I made an example for you. Tell if this is what are you trying to do http://interface.eyecon.ro/demos/sort_example.html Also, please download interface again because I improved a lot things there. Stefan bbuchs wrote: I posted earlier this week about a problem with Interface and the drag/drop/sort functionality. Someone pointed out that my example had an error in IE, so I went back to the drawing board to refactor the code. I've posted three demo pages that explain my problem: http://beta.bryanbuchs.com/index.html http://beta.bryanbuchs.com/index.html http://beta.bryanbuchs.com/index.html http://beta.bryanbuchs.com/index.html http://beta.bryanbuchs.com/index2.html http://beta.bryanbuchs.com/index2.html http://beta.bryanbuchs.com/index3.html http://beta.bryanbuchs.com/index3.html The first link demonstrates that my code isn't entirely wonky - draggables and droppables
