I use Prototype with PHP and love the OO design and some of the utility
functions but I agree the Enumerables possibly aren't worth the extra
bandwidth and performance hit. Has anyone actually done some
performance tests with this? At this point I've done so much with
Prototype that it would take me a long time to convert to another
library, and from what I can tell there are none that are really worth
converting to, they all have problems or quirks. I wouldn't be worried
about it if Prototype was actually being updated, so like many other
people on this board I really believe the project needs to be given up
by Sam to someone like Thomas, or to the community. Thanks for the
initial work buddy, but you can't leave your community hangin out to
dry like this! So many people are making good patches and improvements
but it is really discouraging to both users and contributors when
nothing gets committed! I haven't looked into licensing issues but I
guess it isn't possible for this to just happen? Does Sam have to
officially hand it to someone?
Ryan Gahl wrote:
Protoype is important if only for the ease with which it
enables class based OO programming in js. Yes, we all know... js is a
prototyped based OO language, but using a traditional class approach
makes code re-use, readability, and refactoring (read maintenance) so
much easier. I'm guessing the OP with the beef against proto is more
into procedural style programming (which is FINE, please don't everyone
jump down my throat about that comment... :-)
Proto and scriptaculous have issues, sure... YUI has issues, dojo HAS
issues... you pick the core lib that suites your style and your project
and you fix it where it appears to fall short _for_you_or_your_project,
submitting patches or contributing to the active community surrounding
that core to whatever capacity you can given your limited (or
unlimited) knowledge and time. That, my friend, is how this open source
thing works.
Hopefully the project you pick has a couple of leads in case
_real_life_ issues happen to one of them. Perhaps Sam's dog or mother
has fleas or got sick, or something worse... and as harsh as it may
seem he might just be in a "that whole prototype part of my life can
just wait, and I'm so emotionally drained to even bother trying to
explain it to everyone" state of mind. But, we do have Thomas, who
_can_ get things done, and we could get together and appeal to DHH to
let us in to the SVN server to take proto forward (I vote "not me" as I
don't even use RoR :-))...
I mean, I hear a lot of whining about this, but I honestly doubt all
avenues have been exhausted people.
On 7/19/06, Brandon Aaron <[EMAIL PROTECTED]>
wrote:
I'm all for keeping prototype alive. I think the integration
with RoR is important as well. I absolutely love prototype for the
start it gave me. I've been maintaining my own branch where I've
applied various patches, added functionality of my own, cleaned up the
source and packed it with Dean's packer and/or ShinkSafe and inline
commented several areas for other devs on my team. However, I prefer
the Animation/Effects system that is in Dojo to scriptaculous *ducks*
but scriptaculous has provided some great inspiration. Part of the
functionality I've added to my branch of the library is the dojo
animation/effects system. I don't want to type out namespaces and
manually pass objects all over the place. I've extended the event
system so I can just call e.stop() among other things. If I could find
time for a blog I would love to explain everything I've done and make
it available.
Oh yeah and I really wish the keys to prototype would be passed out to
a select few or Thomas could find some time to commit some community
supported patches. The last commit to prototype was by him.
Brandon
I've
yet to encounter problems. (We only use dragdrop and effects
from scriptaculous.)
If it'll be of use to anyone, I've pasted the bash script I use
below. Be gentle; it was my first-ever bash script.
TAG
#!/bin/bash
#
# SETUP INSTRUCTIONS:
# 1. Compile jsmin.c as found at
http://www.crockford.com/_javascript_/
jsmin.c
# 2. Make it accessible via PATH. This can be likely accomplished
by running
# the following command from wherever you compiled it to:
# ln jsmin /usr/bin/jsmin
# 3. Also make this bash script available to your PATH in a similar
manner
# 4. Run this script from the js folder
#
# PURPOSE:
# If there is a directory "min" in the current working directory,
this script
# checks each "*.js" file to see if a minified copy exists (i.e. a
file with a
# later modified date than the original), if not it runs "jsmin",
adding a
# copyright comment at the top of the minified file.
clear
if [ ! -d min ]; then
echo "The folder 'min' does not exist; unable to minify."
exit 1;
fi
checked=0
minified=0
for i in $(ls *.js); do
# j=${i/%.js/.min.js}
j="min/$i"
if [ ! -f $j ] || [ $i -nt $j ]; then
echo ".. Minifying $i"
jsmin <$i >$j "Minified by jsmin (
http://www.crockford.com/
_javascript_/jsmin.html). See original file in parent folder for full
copyright, terms, and conditions."
let "minified += 1"
else
echo ".. $i is unchanged"
fi
let "checked += 1"
done
echo
echo "Files checked: $checked Files minified: $minified"
echo
On Jul 19, 2006, at 4:44 PM, Hill, Greg wrote:
>> Easy enough to do with jsmin. I have a bash script that will
create
>> a "minified" version of each js file, which takes about 20%
off of
>> each file, on average.
>
> This works well? Last I heard, the 'minifiers' broke on prototype
> because of the lack of block formatting in various places. If
that's
> not the case any more, I'm happy to hear it.
>
>> I don't think min versions need to be in SVN, though.
>
> Not in SVN, but in the zipped release files would be nice.
>
> Greg
> _______________________________________________
> Rails-spinoffs mailing list
>
Rails-spinoffs@lists.rubyonrails.org
>
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
|
