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/
