Why not write a small override lib then, instead of converting the
code... :) ?
best,
thomas
On 20.03.2008, at 22:18, BenKeen wrote:
I have to second Shadow's remark. I've had to turn to jQuery for my
AIR app - a nice little framework, but requires converting my
Prototype code in jQuery
You can lead a horse to water but you can't make em' drink :).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To
Here is a patch for it (I modified 2 lines of code):
Please test and report back on the ticket if it works:
http://dev.rubyonrails.org/ticket/11530
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core
I tested the patch and it turns out that the eval() in the Selector
class isn't a problem becuase Adobe Air uses the compileXPathMatcher()
and bypasses the eval. The only issue must be the evals used for
scripting and the patch takes care of those as well. Other than that I
can't see an issue
Prototype does seem to work out of the box with ADOBE AIR.
The script insertion that the patch for Prototype.exec()
provides does not work under ADOBE AIR, but it does not error out
either.
If you want to eval code you can do somethign like this though, AIR
allows:
function exec(code){
new
Prototype has been using the compileXPathMatcher() for xpath support
since 3/09/07 http://dev.rubyonrails.org/changeset/6366
There shouldn't have been any issues with it since then, unless ADOBE
AIR didn't support XPath until recently. Reguardless Prototype seems
to work just fine.
Basically, what Adobe does is break the specs. We actually had a
conference call with the AIR team a while ago, where they explained
what and why they where doing this.
We feel that we can't follow their reasoning by providing security
or functionality by breaking the specs, so we didn't
