Hi there! My first post to this list, so first of all many thanks for the amazing Scriptaculous library. I''m currently using it for some nice Ajax effects in Apache Cocoon (http://cocoon.apache.org/). I''m currently struggling with Sortable, which I would like to adapt as the conventions used in Cocoon are different from those currently used. Basically, I would like to send back to the server a request saying "move=foo&from=3&to=5", meaning that item 3 in the "foo" element has been moved to position 5. Sortable provides a number of entry points for this, and I though a subclass would do the trick. But contrarily to other effects, Sortable is not a class, which means I can only change it and not extend it to override what needs to be. What''s the rationale for Sortable not being a class? Is making it a class something that can be envisioned? If yes, I''d happily provide a patch for this. Thanks, Sylvain -- Sylvain Wallez Anyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Am 11.10.2005 um 14:24 schrieb Sylvain Wallez:> I''m currently struggling with Sortable, which I would like to adapt > as the conventions used in Cocoon are different from those > currently used. Basically, I would like to send back to the server > a request saying "move=foo&from=3&to=5", meaning that item 3 in the > "foo" element has been moved to position 5. > Sortable provides a number of entry points for this, and I though a > subclass would do the trick. But contrarily to other effects, > Sortable is not a class, which means I can only change it and not > extend it to override what needs to be. > What''s the rationale for Sortable not being a class? Is making it a > class something that can be envisioned? If yes, I''d happily provide > a patch for this.The Sortable object is basically a "factory" for creating lots of draggables and droppables, that''s why it''s implemented as it is. It would sure be welcome if you can come up with a backwards- compatible refactoring that adds support for an underlying class that could be extendable with additional features. :) Thomas
Thomas Fuchs wrote:> Am 11.10.2005 um 14:24 schrieb Sylvain Wallez: > >> I''m currently struggling with Sortable, which I would like to adapt >> as the conventions used in Cocoon are different from those currently >> used. Basically, I would like to send back to the server a request >> saying "move=foo&from=3&to=5", meaning that item 3 in the "foo" >> element has been moved to position 5. >> Sortable provides a number of entry points for this, and I though a >> subclass would do the trick. But contrarily to other effects, >> Sortable is not a class, which means I can only change it and not >> extend it to override what needs to be. >> What''s the rationale for Sortable not being a class? Is making it a >> class something that can be envisioned? If yes, I''d happily provide >> a patch for this. > > > The Sortable object is basically a "factory" for creating lots of > draggables and droppables, that''s why it''s implemented as it is. > It would sure be welcome if you can come up with a backwards- > compatible refactoring that adds support for an underlying class that > could be extendable with additional features. :)Great! I''m nearly there, but would like to know to what are the limits of the contract for backwards compatibility, considering that as Sortable isn''t currently extensible without changing it (i.e. replacing its functions). Basically, what functions and properties of Sortable other than "create()" are considered necessary for backwards compatibility? Sylvain -- Sylvain Wallez Anyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Serialize ? So the examples will work without any changes. Sylvain Wallez wrote:> Thomas Fuchs wrote: > >> Am 11.10.2005 um 14:24 schrieb Sylvain Wallez: >> >>> I''m currently struggling with Sortable, which I would like to adapt >>> as the conventions used in Cocoon are different from those >>> currently used. Basically, I would like to send back to the server >>> a request saying "move=foo&from=3&to=5", meaning that item 3 in the >>> "foo" element has been moved to position 5. >>> Sortable provides a number of entry points for this, and I though a >>> subclass would do the trick. But contrarily to other effects, >>> Sortable is not a class, which means I can only change it and not >>> extend it to override what needs to be. >>> What''s the rationale for Sortable not being a class? Is making it a >>> class something that can be envisioned? If yes, I''d happily provide >>> a patch for this. >> >> >> >> The Sortable object is basically a "factory" for creating lots of >> draggables and droppables, that''s why it''s implemented as it is. >> It would sure be welcome if you can come up with a backwards- >> compatible refactoring that adds support for an underlying class >> that could be extendable with additional features. :) > > > > Great! I''m nearly there, but would like to know to what are the limits > of the contract for backwards compatibility, considering that as > Sortable isn''t currently extensible without changing it (i.e. > replacing its functions). > > Basically, what functions and properties of Sortable other than > "create()" are considered necessary for backwards compatibility? > > Sylvain >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20051011/0856cc4a/attachment.html
I''m doing something like this with lists of lists of lists...
What I do is send back the serialized list on the URL and then
reorder on the server. I wouldn''t want to do it this way if any of
the lists were very long, however.
On a similar note with Sortable, I''ve found an issue that I
don''t
know if is my misunderstanding, a bug with sortable or a gotcha in
JavaScript. I''m writing out quite a few Sortable.create() methods, so
I thought I would just create a loop in JavaScript to create them,
passing in an array. So a whole lot of these:
Sortable.create("group_2284",{ghosting:true,constraint:false,
onUpdate:function(sortable){window.location =
"ReorderWebCategory.action?groupIdsKey=group_2284&" +
Sortable.serialize(sortable);
new Effect.Pulsate(sortable);},
onChange:function(sortable){$(sortable.style.backgroundColor =
"#ffff00");}
});
became one of these first:
var list = [''123'', ''432'',
''4444'', ''2284''];
for(var i = 0; i < list.length; i++){
Sortable.create("group_" + list[i] ,
{ghosting:true,constraint:false,
onUpdate:function(sortable){window.location =
"ReorderWebCategory.action?groupIdsKey=group_" + list[i] +
"&" +
Sortable.serialize(sortable);
new Effect.Pulsate(sortable);},
onChange:function(sortable){$(sortable.style.backgroundColor
= "#ffff00");}
});
The problem with this is that the reference to list always came out
"undefined", so inside the loop I added:
var group = list[i];
and passed in the variable group where list[i] had been. The problem
with this is that for all instances of Sortable.create(), the value
of group is the last item in the array (''2284'' in this
example).
Is this correct behavior? I expected this to act as a closure, but
*group* seems to be passed by reference and getting updated in all
cases during the looped.
Thanks for comments,
Jamie
On Oct 11, 2005, at 8:24 AM, Sylvain Wallez wrote:
> Hi there!
>
> My first post to this list, so first of all many thanks for the
> amazing Scriptaculous library. I''m currently using it for some
nice
> Ajax effects in Apache Cocoon (http://cocoon.apache.org/).
>
> I''m currently struggling with Sortable, which I would like to
adapt
> as the conventions used in Cocoon are different from those
> currently used. Basically, I would like to send back to the server
> a request saying "move=foo&from=3&to=5", meaning that
item 3 in the
> "foo" element has been moved to position 5.
>
> Sortable provides a number of entry points for this, and I though a
> subclass would do the trick. But contrarily to other effects,
> Sortable is not a class, which means I can only change it and not
> extend it to override what needs to be.
>
> What''s the rationale for Sortable not being a class? Is making it
a
> class something that can be envisioned? If yes, I''d happily
provide
> a patch for this.
>
> Thanks,
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://people.apache.org/~sylvain http://www.anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
jonathan wrote:> Serialize ? So the examples will work without any changes. > > Sylvain Wallez wrote:(snip)>> Basically, what functions and properties of Sortable other than >> "create()" are considered necessary for backwards compatibility? >IMHO it would be better to change the samples, as overriding the function of a global object really seems to be a bad thing. What if some code replaces serialize() for its own needs, but other parts of the page expect it to behave as the original implementation? That''s the exact reason why I proposed to change it to a class, so that you can override whatever you want either in subclasses or on instances :-) Sylvain -- Sylvain Wallez Anyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
> > IMHO it would be better to change the samples, as overriding the > function of a global object really seems to be a bad thing. What if > some code replaces serialize() for its own needs, but other parts of > the page expect it to behave as the original implementation? > > That''s the exact reason why I proposed to change it to a class, so > that you can override whatever you want either in subclasses or on > instances :-) >I might misunderstod your question then cause doing a Serialize() function in the Generic class, as you said you could make a sub-classe with an other implementation and that would be perfect :)> Sylvain >
Am 11.10.2005 um 18:03 schrieb Sylvain Wallez:> IMHO it would be better to change the samples, as overriding the > function of a global object really seems to be a bad thing. What if > some code replaces serialize() for its own needs, but other parts > of the page expect it to behave as the original implementation?We can''t do that, as this will break existing code. Just leave the interface to Sortable as-is (.create(), .serialize (), .destroy()), but implement a basic AbstractSortable class, that on can extend. The Sortable object can then use that internally. Sortable.create() should take the class it should create as an option, with the default option being that the behaviour is the same as it currently has. Something like that. Thomas
jonathan wrote:>>IMHO it would be better to change the samples, as overriding the >>function of a global object really seems to be a bad thing. What if >>some code replaces serialize() for its own needs, but other parts of >>the page expect it to behave as the original implementation? >> >>That''s the exact reason why I proposed to change it to a class, so >>that you can override whatever you want either in subclasses or on >>instances :-) >> >> >I might misunderstod your question then cause doing a Serialize() >function in the Generic class, as you said you could make a sub-classe >with an other implementation and that would be perfect :) > >Ah ok. So we agree! Sylvain -- Sylvain Wallez Anyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director