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 draggable>sortable 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 draggable>sortable 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 are working fine. In the second example, all I >> did >> >>> was to >> >>> > include the "isortables" file, and everything goes haywire. In >> >>> the last >> >>> > example, I actually create a sortable list; this stops one >> error >> >>> from >> >>> > occuring, but introduces functionality that I think is just >> >>> wrong. >> >>> > >> >>> > Stefan, I hope you're reading and can take a look at my >> examples. >> >>> > >> >>> > As I mentioned in my last post, I believe the problems stem >> from >> >>> the Sept. >> >>> > 11 2006 modifications that were made; the big update was that >> a >> >>> droppable >> >>> > dropped in a sortable becomes part of the sortable. In my >> >>> opinion, a >> >>> > draggable is a draggable, a droppable is a droppable, and a >> >>> sortable is a >> >>> > sortable. if you want to convert an element from one to the >> >>> other, it should >> >>> > not happen automatically. If it's an option that can be >> passed, >> >>> that's fine, >> >>> > but it should not be the default behaviour. I think my >> examples >> >>> show why the >> >>> > auto-conversion is a bad idea. >> >>> > >> >> >> >> _______________________________________________ >> >> jQuery mailing list >> >> discuss@jquery.com >> >> http://jquery.com/discuss/ >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Interface%3A-draggables%2C-droppables%2C-and-sortables-tf2280438.html#a6431937 >> Sent from the JQuery mailing list archive at Nabble.com. >> >> >> _______________________________________________ >> jQuery mailing list >> discuss@jquery.com >> http://jquery.com/discuss/ >> > > _______________________________________________ > jQuery mailing list > discuss@jquery.com > http://jquery.com/discuss/ > > -- View this message in context: http://www.nabble.com/Interface%3A-draggables%2C-droppables%2C-and-sortables-tf2280438.html#a6439215 Sent from the JQuery mailing list archive at Nabble.com. _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/