Rails spinoffs - Jan 2006 - scriptaculous sortable

Hi,

maybe I am using this the wrong way but I have a list as follows

<ul id="secondlist">
   <li>bla bla</li>
   <li> bla bla </li>
</ul>

and then I add dynamically further <li> elements and create a Sortable 
but the onUpdate only fires for <li> items that have not been created 
via Javascript.

Any clues?

<script type="text/javascript">
 // <![CDATA[
   for(i=0;i<20;i++)
   {
        var node = Builder.node(''li'',
''element''+i);
        $(''secondlist'').appendChild(node);
   }
    Sortable.create("secondlist", {onUpdate:listUpdate,
tag:''li'',
containment:["secondlist"]} );
  
   function listUpdate(){
         alert("update");
   }
 // ]]>
 </script>

> and then I add dynamically further <li> elements and create a
Sortable
> but the onUpdate only fires for <li> items that have not been created
> via Javascript.
> 
I wonder if that''s the same issue I''m having.  My elements
were created
via javascript and I cannot get the onUpdate to fire at all.  At least
that knowledge might help me figure it out.  I''ll be digging into it
more today.

Thanks,
Greg

> > and then I add dynamically further <li> elements and create a
Sortable
> > but the onUpdate only fires for <li> items that have not been
created
> > via Javascript.
> >
> 
> I wonder if that''s the same issue I''m having.  My
elements were
created
> via javascript and I cannot get the onUpdate to fire at all.  At least
> that knowledge might help me figure it out.  I''ll be digging into
it
> more today.
> 
So, my problem was that because I was using innerHTML += ''html code
here''; for some reason the ''id'' on the childNodes
were not being set
correctly.  If I manually set the id in javascript, then the onUpdate
was firing.  That apparently is your issue as well.  The Sortable
determines that something has changed by calling Sortable.serialize()
before and after the drag and comparing the results.
Sortable.serialize() determines it''s value based on the id''s
of the
elements in the Sortable.  They need to be something akin to
''section_24'' (i.e. a word, followed by 1 underscore, then a
distinct
value, such as a numeric id).  This code should fix your problems (only
diff is adding the id''s in both the HTML and Javascript):

<ul id="secondlist">
   <li id="item_1">bla bla</li>
   <li id="item_2"> bla bla </li>
</ul>

<script type="text/javascript">
 // <![CDATA[
   for(i=0;i<20;i++)
   {
        var node = Builder.node(''li'',
''element''+i);
	  node.id = ''item_'' + (node.childNodes.length + 1);
        $(''secondlist'').appendChild(node);
   }
    Sortable.create("secondlist", {onUpdate:listUpdate,
tag:''li'',
containment:["secondlist"]} );
  
   function listUpdate(){
         alert("update");
   }
 // ]]>
 </script>

Greg

Oops, 1 typo in there:
> 	  node.id = ''item_'' + (node.childNodes.length + 1);
node.childNodes.length should be
$(''secondlist'').childNodes.length

Greg

Hi Gregory,

thanks for figuring it out!


Another thing is, Sortable.serialize() returns following string:

Recieved Ajax Request: 
Ajax=true&secondlist%5b%5d=1&secondlist%5b%5d=2&secondlist%5b%5d=3&secondlist%5b%5d=5&secondlist%5b%5d=4&_
Seems strange to me (some sort of Base64 encoding?), do I need to 
specify any specific encoding on the Ajax.request ?

Thanks,

Max

>So, my problem was that because I was using innerHTML += ''html code
>here''; for some reason the ''id'' on the childNodes
were not being set
>correctly.  If I manually set the id in javascript, then the onUpdate
>was firing.  That apparently is your issue as well.  The Sortable
>determines that something has changed by calling Sortable.serialize()
>before and after the drag and comparing the results.
>Sortable.serialize() determines it''s value based on the
id''s of the
>elements in the Sortable.  They need to be something akin to
>''section_24'' (i.e. a word, followed by 1 underscore, then
a distinct
>value, such as a numeric id).  This code should fix your problems (only
>diff is adding the id''s in both the HTML and Javascript):
>
><ul id="secondlist">
>   <li id="item_1">bla bla</li>
>   <li id="item_2"> bla bla </li>
></ul>
>
><script type="text/javascript">
> // <![CDATA[
>   for(i=0;i<20;i++)
>   {
>        var node = Builder.node(''li'',
''element''+i);
>	  node.id = ''item_'' + (node.childNodes.length + 1);
>        $(''secondlist'').appendChild(node);
>   }
>    Sortable.create("secondlist", {onUpdate:listUpdate,
tag:''li'',
>containment:["secondlist"]} );
>  
>   function listUpdate(){
>         alert("update");
>   }
> // ]]>
> </script>
>
>Greg
>_______________________________________________
>Rails-spinoffs mailing list
>Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>  
>

No, that is just normal URL encoding %5b%5d is [], indicating that the
argument should be treated as an array.  I know that many systems will
also create an array from the argument name if it simply passed more
than once in the argument list.  I.E.
secondlist=1,secondlist=2,secondlist=3 would create the array secondlist
= [1,2,3].  But secondlist[]=1,secondlist[]=2,secondlist[]=3 is the
correct way to tell the server that secondlist = [1,2,3].

Greg

Gregory Hill wrote:
> No, that is just normal URL encoding %5b%5d is [], indicating that the
> argument should be treated as an array.  I know that many systems will
> also create an array from the argument name if it simply passed more
> than once in the argument list.  I.E.
> secondlist=1,secondlist=2,secondlist=3 would create the array secondlist
> = [1,2,3].  But secondlist[]=1,secondlist[]=2,secondlist[]=3 is the
> correct way to tell the server that secondlist = [1,2,3].
Ummm... I''m not sure if this is the "correct way". It may be
the normal way for
some languages/frameworks (PHP?), but it''s not standard. Java, C and
Perl (just
a few off the top of my head) don''t do it that the square-bracket way.

-- 
Michael Peters
Developer
Plus Three, LP

> Ummm... I''m not sure if this is the "correct way". It
may be the
normal
> way for
> some languages/frameworks (PHP?), but it''s not standard. Java, C
and
Perl
> (just
> a few off the top of my head) don''t do it that the square-bracket
way.
Well, you may be right, but I do remember reading it somewhere about the
time XHTML came out.  At the time, I don''t believe Perl supported it,
but I think it does now.  I haven''t really tested it out lately,
though,
as I usually just leave the [] off because I always thought it was
rather ugly and it worked fine without it in Perl, which is my language
of choice at the moment.

Now you got me curious... I''m gonna go google it.

Greg

> > Ummm... I''m not sure if this is the "correct way".
It may be the
> normal
> > way for
> > some languages/frameworks (PHP?), but it''s not standard.
Java, C and
> Perl
> > (just
> > a few off the top of my head) don''t do it that the
square-bracket
way.
> 
> Well, you may be right, but I do remember reading it somewhere about
the
> time XHTML came out.  At the time, I don''t believe Perl supported
it,
> but I think it does now.  I haven''t really tested it out lately,
though,
> as I usually just leave the [] off because I always thought it was
> rather ugly and it worked fine without it in Perl, which is my
language
> of choice at the moment.
> 
> Now you got me curious... I''m gonna go google it.
> 
Ok, I stand corrected.  This is something that PHP invented and is
non-standard.  I''m guessing Ruby (or maybe just Rails) also uses this
convention, which is why it''s the default implementation in
scriptaculous.  If you do the variable that way in Perl, you have to
reference it with the brackets in your code as well:

$in{''item[]''} instead of $in{item} (assuming %in is your input
hash).

Although there may be some frameworks that have modified it to work the
same as PHP, I don''t really know.

Greg