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/
