The only actual file you need to update is dragdrop.js
It should be backwards compatible with your current version, but I haven't tested this on browsers other than Safari and Mozilla.
Remember this patch will hopefully be integrated with the main code, and isn't a final version for use in production code.
Sammi
On 18/02/2006, at 10:20 AM, Danger Stevens wrote: I really appreciate the work you put into this and, while I'm just getting into this and have no idea what should be worthy of being added to an official release, I'd really like to use your code.
Have you extracted your changes to a single .js file that can be included after prototype.js and scriptaculous.js? If you have (and I recommend the name: sammi_super_solutions.js) I'd love to use it!
Thanks again!
- Danger
http://dangerstevens.com
On 2/17/06, Sammi Williams <[EMAIL PROTECTED]> wrote: Lets forget about the TAB issue, it isn't really relevant on this
thread.
More actual feedback would be appreciated.
I've replied to everything below, rather than sending individual emails.
In summary, I am hoping this can become an official addition. I
didn't know about $H. I don't need to make modifications to
prototype.js - it has caused a big problem so I will remove this
modification in the next test version I release.
Sammi
On 17/02/2006, at 11:37 PM, Nicolas Terray wrote:
> Is it a real need ? I am not really happy with having to modify
> external library :(
Well, hopefully it becomes a patch, but someone further down has said
I can use $H, which I did not know about, so it may not be necessary
to modify prototype.js
On 18/02/2006, at 12:41 AM, Maninder, Singh wrote:
> Remove the "+" and change it to " " (space)
> http://www.oriontransfer.co.nz/Sortable List v2.zip
Sweet thanks for that I have no idea why that didn't work.. weird.
Otherwise no one would be able to download it.
On the comment of why I use tabs rather than spaces, I'd rather not
go into details but I found that it got pretty messy in web browsers
using spaces for some reason - possibly because there is the
occasional tag. I also feel that spaces should be used for separating
things, while tabs should be used for formatting. For example, in
HTML it is impossible to use more than one space without going to
special lengths. Also, when using tabs, it allows you to set them to
whatever size you want and the code will automaticallly re-adjust.
On 18/02/2006, at 12:39 AM, Todd Ross wrote:
>> Files modified were dragdrop.js and prototype.js.
>
> Unless your modifications to prototype.js are /very/ generic and
> useful to a wider audience than just people who want to sort trees,
> then it's not likely to happen.
The generic modifications I made were Object.values and Object.keys -
but as someone has already pointed out $H should work fine. I figured
they would be pretty useful to anyone. There are also other
modifications to Element but I left them in dragdrop.js for this reason.
On 18/02/2006, at 12:52 AM, Todd Ross wrote:
> You just changed the indenting for the fun of it?
>
> Todd
Um that was from me debugging some weird exceptions thrown by Safari.
But that is fixed now - I didn't realise I made a modification.
On 18/02/2006, at 12:54 AM, Todd Ross wrote:
>> Prototype is a BSD-licensed package; why would they accept code
>
> Bad form to reply to yourself, but I caught this after sending it.
> Prototype is MIT-licensed.
I don't know if I would be happy releasing hours of work under the
MIT license. I prefer the GPL for various reasons, so I'm not sure
what the possibilities are here. Obviously, any changes to
prototype.js can be removed in the new version as $H will be suitable.
On 18/02/2006, at 3:26 AM, Ryan Gahl wrote:
> Sammi, check out some of my recent past posts in the archives RE:
> improving the performance of dragdrop.js...
Yep, I've tried to get in touch with various people who have had
ideas but no one has responded to me.
On 18/02/2006, at 3:28 AM, Ryan Gahl wrote:
> If said library is not performing the tasks you need it to in an
> optimal
> manner, modify and modify now. The alternative is what, live with a
> slow
> application without the features you need?
Yes I would like to optimize it but it would probably require API
changes in dragdrop.js. Unfortunately, in my opinion, there is no
obvious way to optimize this across browsers - but with extensive
profiling and modifications (I have done profiling already and found
some places which need work) it may be possible to make some ground.
On 18/02/2006, at 3:38 AM, Ryan Gahl wrote:
> Sammi, I didn't look at the code, but I would say, keep sending your
> stuff, good stuff. As far as any official patch, who knows. The people
> that need/want the functionality you are offering will take it and run
> with it. Those that don't want a modified core file will figure out
> how
> to take your stuff and factor it into a separate file. Just keep
> contributing like this.
>
> As far as indenting... the fact that the author(s) used spaces for
> indentation in the first place has always been an annoyance. Why not
> just hit the TAB key once and make all tabs equal rather than hitting
> space multiple times and ending up with all sorts of inconsistent
> indentation?
Thanks for your supportive reply, it is nice to hear that you like
the addition - a good three or four weeks went into this modification
- reading through prototype.js and dragdrop.js to figure out how it
was doing things. I think TAB is much better for indentation, that is
what it was created for.. but then let's not get into a flame war
about it.
On 18/02/2006, at 3:40 AM, Nicolas Terray wrote:
> Yes, I understand. But why does your modifications have not been
> integrated ? If they rock, they should be part of the official
> release. Did you receive any answer from prototype and/or
> scriptaculous "maintainers" ?
Yes I have been working with madrobby (Thomas) throughout this whole
process and I guess he will make the final decision of whether it
gets integrated into the main source tree. We are also going to
discuss optimization (the problem of).
On 18/02/2006, at 3:44 AM, Thomas Fuchs wrote:
> Tabs are evil, because they're formatted in different ways on
> different editors.
> Your text editor should allow for switching to soft spaces when you
> hit tab.
> The official scriptaculous/prototype/rails style is 2 spaces
> instead of a tab.
>
> You do use an editor that allows for this, do you...? :)
>
> -Thomas
I use Textmate which has great support for TABs - I can choose what
size I want them to be, and so on. Tabs shouldn't be formatted in
different ways in different editors. A tab can have its width
altered. For example, in Textmate, I can choose for my tab to be 2
spaces, 3 spaces, and so on. I don't see why this is evil? Hitler was
probably evil.. but TAB spacing?
On 18/02/2006, at 4:05 AM, Ryan Gahl wrote:
> Oh ok, that explains it. I guess I never thought tabs were
> formatted so
> differently across IDEs/editors... shouldn't most editors allow
> changing
> how tabs behave (just like as you mentioned for soft tabs)?
>
Exactly!! That is what TABs allow - to easily set your personal
preference. Work on an 80 column terminal? Set your TAB spacing to 1.
Work on a 23" Display? Set your tab spacing to 6. Whatever you need.
> Anyway, my point was, Sammi offered a great contribution and was
> replied
> to with "...and did you just change the indentation for the fun of
> it"?
Yes to be honest I felt a little bit 'breathless' when this guy was
nitpicking without really making his comments constructive.
>
> I change the indentation in my stuff to tabs (which in all my
> experience
> have worked across editors), and I also change the bracket styles from
>
> function() {
> }
>
> To...
>
> function()
> {
> }
>
> ...Those are such matters of preference I think there is no point
> bringing that up in reply to someone's functional contributions. That
> was my real point, just sticking up for Sammi in those matters of
> preference.
Personal choice is great. Thanks for sticking up for me!!
>
> It just makes someone feel like not wanting to contribute further when
> they are picked at for such meaningless stuff. And big deal about his
> licensing line... we all know this stuff is all free for anyone who
> wants it. No one here (or very very FEW if any) of us are lawyers...
> give the guy a break and reply constructively to the functionality,
> not
> nit-picking...
>
> Sorry.
Thanks, I agree with what you are saying. I put a lot of work into
this, so it should be my right to choose what license I release it
under.
On 18/02/2006, at 5:38 AM, Gregory Hill wrote:
> The solution to this is simple.
>
> You make your own js file that overrides functions from the trunk.
> Then
> you can update the trunk and your changes are still included in
> your own
> file.
>
> Greg
Yep, I've done this for some Element.* functions, I realized this was
probably the best way to go. I didn't know about $H.
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
|
PGP.sig