Rails spinoffs - Nov 2007 - finer-grained control on accept behavior for droppables

Hi,

What would be the way to go if I need finer-grained control on what
draggables are accepted by a certain droppable?
I have a directory-tree-like structure, where elements (files,
directories) can get dragged to new positions in the tree.
File-elements are of different types (images, sound, text).
Now, at first it was easy, certain folders would not accept files of
certain types (sound folder will not accept images for example).
This was easily handled by the ''accept'' option in droppables,
since I
give those image-file-elements the ''image'' class.
Now, since folders can be dragged too, I need a little more fine-
grained control, since the ''sounds'' folder should not allow
folders
that contain images to be dropped on it.
Also, on some folders I want to limit the tree-depth, so for example
if a folder containing files and a subfolder is dropped somewhere,
it''s OK, but if the folder has sub-sub-folders, it''s not.
(total depth
can only be 4 for example).

One way I thought of solving this is by using classnames like
''folder_containing_images''  or
''folder_with_2_sublevels" on every
element, but this would quickly become tedious to do since there are
many many combinations.
To automate the process, a lot of code would be needed to adjust
classnames when the tree-structure changes.

It would be much nicer if the ''accept'' option would also allow
a
function as its argument. The function should be passed the draggable,
so it can apply the ''business-rules'' to return true or false.

I checked the dragdrop.js source and it seems I need to overrule
Droppables.isAffected().
I also saw there is a onHover callback which I think can be used
instead of ''accept'' to manually add/remove the hoverclass
after
checking business-rules, but I think this will not stop people from
dropping a not-allowed element anyway (without the visual clues that
the hoverclass provides).

So my guess is I should wrap isAffected.
Am I right?
Or does someone have a better way?

Thanks,
Mathijs


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Try using Sortable.create($(''element_id''),  { tree: true,
treeTag:
''ul'' } );

made an example on http://dizyart.com/unit_tests/sortables.unit.php

On Nov 21, 9:40 pm,
"bluescreen...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<bluescreen...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi,
>
> What would be the way to go if I need finer-grained control on what
> draggables are accepted by a certain droppable?
> I have a directory-tree-like structure, where elements (files,
> directories) can get dragged to new positions in the tree.
> File-elements are of different types (images, sound, text).
> Now, at first it was easy, certain folders would not accept files of
> certain types (sound folder will not accept images for example).
> This was easily handled by the ''accept'' option in
droppables, since I
> give those image-file-elements the ''image'' class.
> Now, since folders can be dragged too, I need a little more fine-
> grained control, since the ''sounds'' folder should not
allow folders
> that contain images to be dropped on it.
> Also, on some folders I want to limit the tree-depth, so for example
> if a folder containing files and a subfolder is dropped somewhere,
> it''s OK, but if the folder has sub-sub-folders, it''s not.
(total depth
> can only be 4 for example).
>
> One way I thought of solving this is by using classnames like
> ''folder_containing_images''  or
''folder_with_2_sublevels" on every
> element, but this would quickly become tedious to do since there are
> many many combinations.
> To automate the process, a lot of code would be needed to adjust
> classnames when the tree-structure changes.
>
> It would be much nicer if the ''accept'' option would also
allow a
> function as its argument. The function should be passed the draggable,
> so it can apply the ''business-rules'' to return true or
false.
>
> I checked the dragdrop.js source and it seems I need to overrule
> Droppables.isAffected().
> I also saw there is a onHover callback which I think can be used
> instead of ''accept'' to manually add/remove the hoverclass
after
> checking business-rules, but I think this will not stop people from
> dropping a not-allowed element anyway (without the visual clues that
> the hoverclass provides).
>
> So my guess is I should wrap isAffected.
> Am I right?
> Or does someone have a better way?
>
> Thanks,
> Mathijs
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

At first I didn''t find a way to make an element take up new child
elements, i.e. a way to make item2 (sibling of item1) go "under" item1

Then I inserted a "faux" UL inside every LI under the tree element (do
this before you start the sortable). Since this didn''t work, I had to
make an empty LI inside every faux UL. Set some on-the-fly CSS (height
of the faux LI has to be more than 1px, otherwise it''s hard to hit the
right spot) and you have yourself a LI that accepts new items to it''s
hidden UL.

here''s the complete function:

//// CREATE SORTABLE TREE LIST WHICH ACCEPTS NEW CHILD ELEMENTS

function sortableTreeAdvanced(element){

	element = $(element);
	element.select(''li'').each( // this is each LI recursive
	function (li){
		if (!li.down(''ul'')){ // make sure that an child UL does not
already
exist
                        /// now let''s create a faux UL, which is more-
or-less hidden, so it can accept new mushrooms
			var fauxUL=document.createElement(''ul'');
			var fauxLI=document.createElement(''li'');
			fauxLI.style.height = ''3px'';
			fauxLI.style.listStyleType = ''none'';
			fauxUL.appendChild(fauxLI);

			li.appendChild(fauxUL); // put the hidden list inside the LI
		}
	}); /// end each LI

	Sortable.create(element, { tree:true, treeTag:''ul''} );

}

sortableTreeAdvanced(''sortable_test'');
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for answering but this isn''t what I meant.
I know about tree sorting, not using it for this project though.
My question was about telling a droppable (or sortable if I would go
for your suggestion) what kind of elements to accept, and which not.
So for some folder (node) it''s OK to receive a subfolder, but for
another it''s not.
The rules as to what to accept can be more complex than just css class
names, so I was asking for a way around the standard ''accept''
option
behavior on droppables (or sortables for that sake).

Thanks anyway :)


On 22 nov, 01:40, LexNonScripta
<lex.non.scri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> At first I didn''t find a way to make an element take up new child
> elements, i.e. a way to make item2 (sibling of item1) go "under"
item1
>
> Then I inserted a "faux" UL inside every LI under the tree
element (do
> this before you start the sortable). Since this didn''t work, I had
to
> make an empty LI inside every faux UL. Set some on-the-fly CSS (height
> of the faux LI has to be more than 1px, otherwise it''s hard to hit
the
> right spot) and you have yourself a LI that accepts new items to
it''s
> hidden UL.
>
> here''s the complete function:
>
> //// CREATE SORTABLE TREE LIST WHICH ACCEPTS NEW CHILD ELEMENTS
>
> function sortableTreeAdvanced(element){
>
>         element = $(element);
>         element.select(''li'').each( // this is each LI
recursive
>         function (li){
>                 if (!li.down(''ul'')){ // make sure that an
child UL does not already
> exist
>                         /// now let''s create a faux UL, which is
more-
> or-less hidden, so it can accept new mushrooms
>                         var
fauxUL=document.createElement(''ul'');
>                         var
fauxLI=document.createElement(''li'');
>                         fauxLI.style.height = ''3px'';
>                         fauxLI.style.listStyleType =
''none'';
>                         fauxUL.appendChild(fauxLI);
>
>                         li.appendChild(fauxUL); // put the hidden list
inside the LI
>                 }
>         }); /// end each LI
>
>         Sortable.create(element, { tree:true,
treeTag:''ul''} );
>
> }
>
> sortableTreeAdvanced(''sortable_test'');
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---