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
>> [email protected]
>> 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
[email protected]
http://jquery.com/discuss/
_______________________________________________ jQuery mailing list [email protected] http://jquery.com/discuss/
