Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Archive

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

Moving to Prototype 1.5 and other JS issues


Go to End
Reply

10 Posts   6232 Views

Avatar
qhoxie

14 August 2007 at 7:18am Google Summer of Code Hacker, 39 Posts

hey everyone,

this is something that i have been looking to bring up for a while, so i thought i would kick off a discussion about moving to prototype 1.5 is silverstripe
i imagine the core devs have already discussed this to some extent

in my reporting project, i make use of 2 plugins that require the 1.5 branch of prototype, so this puts a bit of a personal motive behind this, but all that aside, this mildly significant update has been out for about 7 months, so i think it behooves us to see what can be done to adapt current scripts to be compatible

so here is what i propose, people post about their individual projects and why/how/if they are affected by the update
also input from the core devs would be great, as im sure they already know of incompatibilities in the core

the next issue is one that has come up in the past, but i believe that there is more to be discussed about it
the issue is javascript compression. there are a lot of good compressors out there, and i rarely hear convincing arguments that one is better than another
i personally feel good using dean's [url=http://dean.edwards.name/packer/]packers[/url]

we all know that there is a lot of js in silverstripe, and not everyone uses gzipping on their web servers, so i think distributing compressed scripts, or the option of using compressed scripts would be beneficial, maybe something in _config could specify to used prototype.js or prototype_compressed.js, etc

last issue that comes to mind is another one dealing with optimization
there has been a good amount of work done in the last year or so primarily on improving window.onload ready speed
it started with dean edwards and alex russell but it has grown quite a bit, and i think the most mature/robust incarnation is the [url=http://www.tetlaw.id.au/view/javascript/fastinit]fastinit script[/url] which combines a variety of improvements, the most notable of which is that onload does not wait for images to load

i think this would be a welcome addition to silverstripe, making the cms appear much more responsive in certain cases

anyway these are some of my thoughts, any discussion is appreciated

recap: prototype 1.5 -> compression -> onload optimization

Avatar
wakeless

14 August 2007 at 9:34am 5 Posts

Regardless of the packing/compression issues (which I think should probably be left to a project by project issue) Prototype1.5 is a pretty huge step up. Patching SS to be compatible is not that difficult, there are just a few functions that have been removed in 1.5 that cause problems,

Ajax.SubmitForm, Ajax.Evaluator, and Form.serializeWithoutButtons

Avatar
Tim

14 August 2007 at 10:48am (Last edited: 14 August 2007 11:39am), Core Development Team, 201 Posts

Thanks for bringing these things up, take a look at the tow following posts for some background on this - [url=http://www.silverstripe.com/feature-requests/flat/964]Javascript Compressors[/url] and a off topic discussion on [url=http://www.silverstripe.com/google-summer-of-code-forum/flat/1757] Prototype 1.5 [/url]

In short I agree 100% with you that doing these things would be a great idea, however there would be a lot of work required. Regarding upgrading to prototype 1.5, I think this would be best done as we deploy the [url=http://www.silverstripe.com/silverstripe-development/flat/3799]new interfaces[/url] as that is going to require a large amount of work in its own right.

The counter to this is if you think you can pull of a 1.5 upgrade with a few days work.. now, that would be pretty legendary :P You may want to talk with Elijah about this :P

Avatar
qhoxie

14 August 2007 at 11:18am Google Summer of Code Hacker, 39 Posts

thanks tim, ive seen the discussions you mentioned, though i had forgotten about the prototype stuff in elijahs thread

i agree that deploying the new interface with 1.5 is a wise decision

as for compression, i was hoping to get a bit of a continuation on that thread and maybe finalize some ideas, as there are a number of routes that could be taken

Avatar
wakeless

14 August 2007 at 2:49pm 5 Posts

Hi guys, I'm attaching a patch that should upgrade Prototype and Scriptacolous, I've left backwards compatible changes in prototype_improvements.js

This should work against 2.0.2

Avatar
Tim

14 August 2007 at 3:40pm Core Development Team, 201 Posts

Hey wakeless, would love to see what you've come up with :-)

Avatar
wakeless

14 August 2007 at 4:20pm 5 Posts

Sorry bout that, I though I'd uploaded it... its here anyway.

http://dev.wakeless.net/prototype1.5.diff

Avatar
Ingo

17 August 2007 at 8:54am Forum Moderator, 801 Posts

> Hi guys, I'm attaching a patch that should upgrade Prototype and Scriptacolous, I've left backwards compatible changes in prototype_improvements.js

that patched the third-party stuff, but nothing silverstripe-specific (CMSMain etc) - this is where the fun starts ;) as mentioned in the thread linked by tim, silverstripe's implementation is heavily customized. i've attached my previous patch-attempts for ss-specific js in which got 1.5 running, and the cms loading. there's a couple of man-days testing needed before any of this can go into production, though. plus they are slightly outdated (04/2007).

> it started with dean edwards and alex russell but it has grown quite a bit, and i think the most mature/robust incarnation is the fastinit script which combines a variety of improvements, the most notable of which is that onload does not wait for images to load

prototype 1.6rc1 had onDomLoad-support built in - the final release will probably coincide with us switching over, so we might as well skip prototype 1.5. it could work pretty well with the sitetree, as its loaded early in the DOM, and before any heavy processing is done for tinymce and the content-area.

Go to Top