[Prototype-core] Re: Dox Typo
Thanks for the heads up. I've updated the CHM version. On 3/20/07, Richard Quadling [EMAIL PROTECTED] wrote: On 20/03/07, Mislav Marohnić [EMAIL PROTECTED] wrote: Whilst this will be fixed, is there a central repository (CVS/SVN) for the dox? If so, where? Not needing karma, just read access. No such thing - we used Mephisto, so everything is in its database in form of articles. If you want to download alternative formats, use Atom feeds in API sections or PDF/CHM bundles. Ok. Thanks. Screen scrape it is then to automate a CHM build. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- Regards, Kjell www.m3nt0r.de --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Compressed Prototype: Protopacked_v2d
Instructions:
* This pack contains the following compressed versions of Prototype:
moo.fx Lite, 1.4, 1.5_rc0, 1.5_rc1, 1.5 final, 1.5.1_rc2
* The root folder has an example using one of the smallest Prototype
1.5 Final forms in this package.
* prototype.js is prototype-1.5.0 (final)-ultra.js
* prototype_alt.js is prototype-1.5.0 (final)-packer (safari
2.0.4).js
Download available under the Files link.
Open the protopacked files folder.
There choose either 'original', 'formatted', or 'compressed'.
OriginalThe original unmodified forms of all the Prototype
versions.
Formatted The formatted forms of all the Prototype versions.
These versions contain all the semicolons, regExp mods and
such
that make them work with the compressors.
Compressed The compressed forms of all the Prototype versions.
Each version, except lite, has 6 different compressed
forms.
- custom: uses my custom compression (a bit slow on the
decode, I
am working on that)
- mem: compressed with the memtronics compressor
- nowhitespace: removed whitespace and comments from
the file
(Deans Packer set to none on the compression option).
- packer: compressed with Dean Edward's packer \w High
ASCII
compression
- packer-(safari 2.0.4) : compressed with Dean Edward's
packer \w
Normal compression
- ultra : memtronics version compressed again with my
custom
compressor.
Gzipped The gzipped folders contain the gzipped forms of all
the scripts in the current folder.
Realistically, I would stick to the gzipped nowhitespace versions.
They have no js compression, which means no startup delay.
They are also the smallest file size (Prototype 1.5 final is 13kb).
To load gzipped files you need to go through a server side language
such as PHP.
Some have used the .gz file directly but that's not universally
supported.
* Andrea Giammarchi has created a great GzOutput.class for PHP 5.
* Use in conjunction with the nowhitespace js versions to get the
best of the gzipped goodness.
* http://www.devpro.it/php5_id_145.html
* http://webreflection.blogspot.com/
Example usage:
Good:
script type=text/javascript src=gz.php?src=prototype/
script
Bad:
script type=text/javascript src=prototype.gz/script
If you use the js None High ASCII compressed files usage is
like a normal js file:
script type=text/javascript src=prototype.js/script
If you use the js High ASCII compressed files then usage is:
script type=text/javascript src=protopacked.js?
load=prototype.js,prototype_alt.js/script
OR
script type=text/javascript src=protopacked.js?load=gz.php?
src=prototype,gz.php?src=prototype_alt/script
Safari 2.0.4/Omniweb 5.5.4 have a bug in them that causes certian
High ASCII text in eval()'s to error out.
For example: eval('if(//.¡());'.replace(/¡/g,'test'));
To solve this issue I created a loader, 'protopacked.js', that
detects if the browser supports
High ASCII. If it does it loads the first High ASCII file, if not
it loads the
second None High ASCII file.
The loader is only 389bytes (less than half of 1kb).
The loader supports any filename in the same directory as itself.
Filenames are separated by a ',' (2 files are required, no spaces
between the ,'s)
I believe the bug is isolated to applications built around the webkit
version at the time.
Nightly builds of webkit have been tested successfully as far back as
Sept of 06.
High ASCII encoded files:
custom
memtronics
packer
ultra
Non High ASCII encoded files:
original
formatted
nowhitespace
packer-(safari 2.04)
Tested successfully on:
win:
opera 9.10
firefox 2.0.0.1
ie 7.0
ie 6.0.2
ie 5.5
mac :
firefox 1.5.01
firefox 2.0.0.2
camino 1.0.4
opera 9.1
omniWeb 5.1.3
safari 1.3.2
safari 2.0.2
webkit 2.0.4 (nightly build)
safari 2.0.4 (limited support)
omniweb 5.5.4 (limited support)
Tested unsuccessfully on:
win:
ie 5.1
mac :
ie 5.2
opera 6.3
safari 2.0.4 (High ASCII)
omniweb 5.5.4 (High ASCII)
Troubleshooting:
If you have issues with the compressed custom/memtronics/ultra
files, try using the charset iso-8859-1
script
[Prototype-core] Re: Node Insertion Methods
On 3/20/07, Ken Snyder [EMAIL PROTECTED] wrote: insertAfter (complement of insertBefore) prependChild (complement of appendChild) addNodeBefore addNodeAfter I like these. I used similar ones for some time now as a part of an add-on script. I think these should be a part of the Insertion rewrite. --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
Definitely aggreed. Could we go for somethign a bit more consistent in the naming though ? append = Insertion.Top prepend = Insertion.Bottom addBefore = Insertion.Before addAfter = Insertion.After Best, Tobie On Mar 20, 12:15 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On 3/20/07, Ken Snyder [EMAIL PROTECTED] wrote: insertAfter (complement of insertBefore) prependChild (complement of appendChild) addNodeBefore addNodeAfter I like these. I used similar ones for some time now as a part of an add-on script. I think these should be a part of the Insertion rewrite. --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
Hey, Tobie Langel a écrit : append = Insertion.Top prepend = Insertion.Bottom OK, but... the other way around! :-) -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
lol On Mar 20, 1:58 pm, Christophe Porteneuve [EMAIL PROTECTED] wrote: Hey, Tobie Langel a écrit : append = Insertion.Top prepend = Insertion.Bottom OK, but... the other way around! :-) -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Ajax.Request with method different from GET or POST
Hi, I was about to use Prototype for its Ajax.Request facilities but soon noticed that the method has to be GET or POST, otherwise it is converted to a POST (as a new entry in the params Hash). What if I want to issue a PUT with payload in the postBody (er, *post*Body for a PUT?!)? params is not used but the method is already changed to POST. Couldn't it be possible that if postBody (maybe renamed to requestBody ?) is provided then the method is kept as-is? What if I want to issue DELETE (of course without params or postBody)? Couldn't it be possible to have a rewriteMethod flag (eventually defaulting to true for backward compatibility) to turn method rewriting to POST off? Or am I missing something in the use of Ajax.Request? or is there another way to use XMLHttpRequest with Prototype? or should I just not use Prototype? Thanks in advance, Thomas Broyer --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request with method different from GET or POST
On 3/20/07, Thomas Broyer [EMAIL PROTECTED] wrote: Couldn't it be possible to have a rewriteMethod flag (eventually defaulting to true for backward compatibility) to turn method rewriting to POST off? Yeah, there's a ticket in the issue tracker for that. I think we should definitely have an option *not* to override the given HTTP method so that advanced users may still use Prototype. Or am I missing something in the use of Ajax.Request? or is there another way to use XMLHttpRequest with Prototype? or should I just not use Prototype? Until we add this option to trunk, you can patch Ajax.Request yourself. Simply locate the _method hack and wrap it up in a conditional based on the specific parameter in the options hash. The only person right now who knows if you should use Prototype is you. If you want an easy, beautiful and cross-platform API for leveraging XHR in your web sites/apps, then you can't go wrong with Prototype. --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request with method different from GET or POST
Hi Thomas- On Mar 20, 2:23 pm, Thomas Broyer [EMAIL PROTECTED] wrote: Hi, I was about to use Prototype for its Ajax.Request facilities but soon noticed that the method has to be GET or POST, otherwise it is converted to a POST (as a new entry in the params Hash). What if I want to issue a PUT with payload in the postBody (er, *post*Body for a PUT?!)? params is not used but the method is already changed to POST. Couldn't it be possible that if postBody (maybe renamed to requestBody ?) is provided then the method is kept as-is? What if I want to issue DELETE (of course without params or postBody)? Couldn't it be possible to have a rewriteMethod flag (eventually defaulting to true for backward compatibility) to turn method rewriting to POST off? There are various issues with using methods other than GET and POST in Internet Explorer and Safari. The short answer is that, at least for today's browsers, you must piggyback on POST for these verbs and implement server-side support for the _method parameter (Rails does this automatically). -sam --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] CSS syntax for node creation?
Just a thought, if a future version of prototype were to include a
simple element creation method, what about using CSS syntax for
specification of id and class? i.e.:
var node = new Element('div#mynode.someClass');
Could the new CSS3 parser be easily reused to implement this? I looked
at it briefly but it's pretty complex :)
Good idea or bad?
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: CSS syntax for node creation?
That's an interesting idea.
Parts of CSS3 parser could be reused. You could certainly use the
regexen we define to identify various CSS tokens.
My first thought was that combinators should not be allowed in that
syntax (i.e. new Element('div#mynode div.someClass'), but then I
suppose you could use such a syntax to mean create a div with a class
of 'someClass', then append it to the already-existing div with an id
of 'mynode'. That could get pretty complicated pretty fast, though.
What do other people think?
Cheers,
Andrew
On Mar 20, 3:31 pm, Colin Mollenhour [EMAIL PROTECTED] wrote:
Just a thought, if a future version of prototype were to include a
simple element creation method, what about using CSS syntax for
specification of id and class? i.e.:
var node = new Element('div#mynode.someClass');
Could the new CSS3 parser be easily reused to implement this? I looked
at it briefly but it's pretty complex :)
Good idea or bad?
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Hash.toQueryString changes
Michael Peters is correct. Since forms of type application/x-www-form-urlencoded *do not* add brackets to inputs so neither should this method. PHP is my primary server side language and our form elements are named 'foo[]' if we want them to become an array on the serverside. Its up to the dev to name their form elements properly not the JS Framework to magically know. Also, as to the other points. I think that consistency is key. If its null in then its null out (doesnt even appear in the render). As to marking it null in the first place I am for it. It makes a smaller query string if you have a bunch of nulls. If you want them nulls to show up I, i set them to an empty string instead of null. Good discussion. --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] CSS syntax for node creation?
That would certainly be unique and powerful. What would this
hypothetical class allow? Consider the following:
Create and Append at Position-- new Element('#content div#mynode.someClass')
Define Attributes-- new Element('[EMAIL PROTECTED]text]')
Create an Array of Nodes-- new Element('#address li.errors span')
The more I think about it, the more my brain hurts. Not sure if that
means it is a good idea or not :P
--Ken
Colin Mollenhour wrote:
Just a thought, if a future version of prototype were to include a
simple element creation method, what about using CSS syntax for
specification of id and class? i.e.:
var node = new Element('div#mynode.someClass');
Could the new CSS3 parser be easily reused to implement this? I looked
at it briefly but it's pretty complex :)
Good idea or bad?
--~--~-~--~~~---~--~~
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
On 3/20/07, Tobie Langel [EMAIL PROTECTED] wrote: I'd be in favor or having element methods which deal with both. +1 Four methods at most should do the trick. --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Node Insertion Methods
Don't use .down and .next with no arguments unless you need non-text nodes. It is very inefficient in this case. next grabs all nextSibling elements recursively (potentially many, extending each one in the process) and then just returns the first one. down grabs *all* descendants, then loops through extending each one, and then returns the first one. I suggest only using those methods if you need guarantees that you are getting a DOM element and not a text node. In this case I would argue that you *do* want text nodes. Consider: You might want to check out the patch I submitted some days ago. It'll optimize this (calling down/up etc without arguments): http://dev.rubyonrails.org/ticket/7848 --~--~-~--~~~---~--~~ 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 unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
