Re: [mochikit] Does anyone use this?
If you ever had any interest in taking over maintenance or contributing in any way, I'd be happy to let you run with it. On Fri, May 26, 2017 at 5:24 PM, Chris Snyder wrote: > Um, I still use it daily, on projects new and old. It gets the job done, > and the logo makes me happy. > > I charge extra if a client insists on jQuery. > > On May 25, 2017, at 11:04 PM, Bob Ippolito wrote: > > I don't think anyone is building anything new on MochiKit at this point. > We sure did pioneer a lot of stuff people are doing today over a decade > ago, but frankly all of the ideas are really just from other places outside > the browser :) > > On Thu, May 25, 2017 at 20:01 Chaz Gatian wrote: > >> I stumbled upon MochiKit for the first time tonight, and it completely >> blew my mind. >> >> I started web development eight years ago, and have never heard of such a >> tool. It's so interesting to read the blogs, and issues from the past. From >> what I can tell this library seems like the first framework to try to solve >> all the different browser quirks, something I always thought jQuery was the >> first to accomplish. But now having learned about this framework, I might >> be *VERY *wrong! >> >> If anyone still frequents this group please say something, I'm curious to >> know if anyone is still using this in applications today. >> >> -Chaz >> >> -- >> You received this message because you are subscribed to the Google Groups >> "MochiKit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mochikit+unsubscr...@googlegroups.com. >> To post to this group, send email to mochikit@googlegroups.com. >> Visit this group at https://groups.google.com/group/mochikit. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To unsubscribe from this group and stop receiving emails from it, send an email to mochikit+unsubscr...@googlegroups.com. To post to this group, send email to mochikit@googlegroups.com. Visit this group at https://groups.google.com/group/mochikit. For more options, visit https://groups.google.com/d/optout.
Re: [mochikit] Does anyone use this?
MochiKit was started specifically because Prototype didn't suit my needs and didn't have sufficient docs or tests :) On Thu, May 25, 2017 at 23:56 Arnar Birgisson wrote: > Prototype was one of the main contenders towards the end, before jQuery > took over. When I started using mochi it was between it and mootools > however (winter 2005-2006). jQuery, and I think Prototype as well, came > later. I distinctly remember picking mochikit because of its documentation > and module structure. > > Must say thanks to Bob, Thomas, and Per for putting it out and > maintaining. It was an enormous value in my work back then, and I'm sure > that code is still running at my old company. > > ab > > On Thu, May 25, 2017 at 11:32 PM troels knak-nielsen < > tro...@knak-nielsen.dk> wrote: > >> Whoa. Blast from the past. >> >> Mochi was way ahead of the curve 10 years ago. I used it last around >> 2009. At that point jquery had sort of taken the position, as I remember it. >> >> For sake of a bit of code archeology, there were definitely other tool >> kits even before Mochi. I think xb (xbrowser?) was one of my go-to staples >> for a while. >> >> T >> >> On Fri, 26 May 2017 at 05.01, Chaz Gatian >> wrote: >> >>> I stumbled upon MochiKit for the first time tonight, and it completely >>> blew my mind. >>> >>> I started web development eight years ago, and have never heard of such >>> a tool. It's so interesting to read the blogs, and issues from the past. >>> From what I can tell this library seems like the first framework to try to >>> solve all the different browser quirks, something I always thought jQuery >>> was the first to accomplish. But now having learned about this framework, I >>> might be *VERY *wrong! >>> >>> If anyone still frequents this group please say something, I'm curious >>> to know if anyone is still using this in applications today. >>> >>> -Chaz >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "MochiKit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to mochikit+unsubscr...@googlegroups.com. >>> To post to this group, send email to mochikit@googlegroups.com. >>> Visit this group at https://groups.google.com/group/mochikit. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "MochiKit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mochikit+unsubscr...@googlegroups.com. >> To post to this group, send email to mochikit@googlegroups.com. >> Visit this group at https://groups.google.com/group/mochikit. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To unsubscribe from this group and stop receiving emails from it, send an email to mochikit+unsubscr...@googlegroups.com. To post to this group, send email to mochikit@googlegroups.com. Visit this group at https://groups.google.com/group/mochikit. For more options, visit https://groups.google.com/d/optout.
Re: [mochikit] Does anyone use this?
I don't think anyone is building anything new on MochiKit at this point. We sure did pioneer a lot of stuff people are doing today over a decade ago, but frankly all of the ideas are really just from other places outside the browser :) On Thu, May 25, 2017 at 20:01 Chaz Gatian wrote: > I stumbled upon MochiKit for the first time tonight, and it completely > blew my mind. > > I started web development eight years ago, and have never heard of such a > tool. It's so interesting to read the blogs, and issues from the past. From > what I can tell this library seems like the first framework to try to solve > all the different browser quirks, something I always thought jQuery was the > first to accomplish. But now having learned about this framework, I might > be *VERY *wrong! > > If anyone still frequents this group please say something, I'm curious to > know if anyone is still using this in applications today. > > -Chaz > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To unsubscribe from this group and stop receiving emails from it, send an email to mochikit+unsubscr...@googlegroups.com. To post to this group, send email to mochikit@googlegroups.com. Visit this group at https://groups.google.com/group/mochikit. For more options, visit https://groups.google.com/d/optout.
Re: [mochikit] Multiselect List
On Sun, Oct 16, 2011 at 6:09 AM, Jurgens de Bruin wrote: > Hi, > > I am very new to mochiKit and would appreciate some help. > > I have a form containing a multi-select list, I am try to use AJAX and > JSON to produce async tasks. Currently I can't get all the selected > elements from the multi-select list passed to the server. > > How can I obtained all selected elements from the list after submit > has been click? http://mochi.github.com/mochikit/doc/html/MochiKit/Signal.html#fn-connect https://developer.mozilla.org/en/DOM/element.onchange http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html#fn-formcontents http://mochi.github.com/mochikit/doc/html/MochiKit/Base.html#fn-serializejson http://mochi.github.com/mochikit/doc/html/MochiKit/Async.html#fn-doxhr http://mochi.github.com/mochikit/doc/html/MochiKit/Async.html#fn-evaljsonrequest -bob -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: Is MochiKit Dead?
Sure, if you'd like to roll these upstream and make a new release of MochiKit out of it I think that's a fine idea. It looks like you've already got access to the MochiKit team, so go for it whenever you're ready. On Wed, Aug 17, 2011 at 6:17 AM, Fredrik Blomqvist wrote: > I've had similar thoughts. jQuery is "king of the DOM" nowadays, no > need/use to compete with overlapping low-level features there. I think > the Python heritage should continue to be embraced though. When > looking at underscore lib I kindof like it but that's mostly because > lots of it already exists in MK ;) Looks like MK.Base + Iter interface > (but without actual iterator code). > > I added couple of draft libraries to my MochiKit fork last year. > https://github.com/blq/mochikit - > http://blq.github.com/mochikit/doc/html/MochiKit/index.html > > To keep things moving perhaps parts of these could be added? > Improved binding etc > http://blq.github.com/mochikit/doc/html/MochiKit/Base-ext.html > Resembles "rest of" the Python itertools module: > http://blq.github.com/mochikit/doc/html/MochiKit/Iter-ext.html > Resembles the Python Bisect module > http://blq.github.com/mochikit/doc/html/MochiKit/Bisect.html > Resembles the Python HeapQ module > http://blq.github.com/mochikit/doc/html/MochiKit/HeapQ.html > http://blq.github.com/mochikit/doc/html/MochiKit/Random.html > ... (see the changelog) > Code annotation and build scripts to integrate with Google Closure > compiler is also added. > > Feedback welcome! > Regards > // Fredrik Blomqvist > > > On Aug 15, 5:56 am, Bob Ippolito wrote: >> I agree, if I had a good reason I would split MochiKit up into smaller >> components that built on top of jQuery and perhaps backbone and/or >> underscore. I only have direct experience with jQuery but I've heard >> good things from smart people about backbone and underscore. jQuery is >> a fine library for DOM stuff but it really just doesn't do much of the >> more interesting stuff that MochiKit has done for years. >> >> >> >> >> >> >> >> On Sun, Aug 14, 2011 at 11:27 AM, Per Cederberg >> wrote: >> > Agreed. Nowadays I'm also in maintenance-only-mode with respect to >> > MochiKit. Meaning that I'll only address critical bugs or merge >> > well-documented & tested patches. The MochiKit.Text module and version >> > 1.5 won't progress further unless someone else steps up to do the >> > work. >> >> > That said, I'm still using MochiKit where it makes sense. Preferably >> > in conjunction with jQuery. Would be nice to eventually package up >> > MochiKit into separate pieces that glue better into jQuery in some >> > ways. But the custom packaging solution we have right now also allows >> > to strip out some obvious duplicated stuff... >> >> > Cheers, >> >> > /Per >> >> > On Sat, Aug 13, 2011 at 20:45, Bob Ippolito wrote: >> >> On Sat, Aug 13, 2011 at 11:35 AM, machineghost >> >> wrote: >> >>> So, given that: >> >> >>> * There hasn't been a blog post on the website in ... ever (according >> >>> to the front of the site; in reality there was a post back in 2008) >> >>> * There hasn't been a release since 2008 >> >>> * This mailing list gets a post (with no response) once every other >> >>> month or so, if that >> >>> * MochiKit is less popular than random frameworks I've never heard of >> >>> (xajax? what's that?) by a factor of six (http://www.readwriteweb.com/ >> >>> hack/2011/08/javascript-framework-popularit.php) >> >> >>> it really seems like MochiKit is a dead project, or at best a zombie >> >>> project. Is that accurate? I mean, obviously people currently using >> >>> it aren't going to stop, but is new development, promotion of the >> >>> framework, improvement of the website/docs/etc. dead? >> >> >> Zombie sounds about accurate to me, we still use it but it's done what >> >> we've needed it to do for quite a few years so we haven't bothered to >> >> make any changes to it. We don't have a lot of incentive to encourage >> >> other people to use it, especially at this point. If someone is >> >> interested in making improvements they're more than welcome to do so, >> >> it's all pretty much github based these days so accepting pull >> >> requests, adding contributors
Re: [mochikit] Is MochiKit Dead?
Good idea. Done! On Mon, Aug 15, 2011 at 4:20 AM, Chris Snyder wrote: > Not Dead: Feature Complete. > > Since this issue comes up every year or so, I think there should be a > simple explanation on the website homepage, something like: > > MochiKit is considered "feature complete" at version 1.4, and is > therefore not in active development. It simply does what we have > needed it to do for quite a few years so we haven't bothered to make > any major changes to it. Contributions and improvements are welcome > via GitHub. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Is MochiKit Dead?
I agree, if I had a good reason I would split MochiKit up into smaller components that built on top of jQuery and perhaps backbone and/or underscore. I only have direct experience with jQuery but I've heard good things from smart people about backbone and underscore. jQuery is a fine library for DOM stuff but it really just doesn't do much of the more interesting stuff that MochiKit has done for years. On Sun, Aug 14, 2011 at 11:27 AM, Per Cederberg wrote: > Agreed. Nowadays I'm also in maintenance-only-mode with respect to > MochiKit. Meaning that I'll only address critical bugs or merge > well-documented & tested patches. The MochiKit.Text module and version > 1.5 won't progress further unless someone else steps up to do the > work. > > That said, I'm still using MochiKit where it makes sense. Preferably > in conjunction with jQuery. Would be nice to eventually package up > MochiKit into separate pieces that glue better into jQuery in some > ways. But the custom packaging solution we have right now also allows > to strip out some obvious duplicated stuff... > > Cheers, > > /Per > > On Sat, Aug 13, 2011 at 20:45, Bob Ippolito wrote: >> On Sat, Aug 13, 2011 at 11:35 AM, machineghost >> wrote: >>> So, given that: >>> >>> * There hasn't been a blog post on the website in ... ever (according >>> to the front of the site; in reality there was a post back in 2008) >>> * There hasn't been a release since 2008 >>> * This mailing list gets a post (with no response) once every other >>> month or so, if that >>> * MochiKit is less popular than random frameworks I've never heard of >>> (xajax? what's that?) by a factor of six (http://www.readwriteweb.com/ >>> hack/2011/08/javascript-framework-popularit.php) >>> >>> it really seems like MochiKit is a dead project, or at best a zombie >>> project. Is that accurate? I mean, obviously people currently using >>> it aren't going to stop, but is new development, promotion of the >>> framework, improvement of the website/docs/etc. dead? >> >> Zombie sounds about accurate to me, we still use it but it's done what >> we've needed it to do for quite a few years so we haven't bothered to >> make any changes to it. We don't have a lot of incentive to encourage >> other people to use it, especially at this point. If someone is >> interested in making improvements they're more than welcome to do so, >> it's all pretty much github based these days so accepting pull >> requests, adding contributors and updating the site is very easy. >> >> -bob >> >> -- >> You received this message because you are subscribed to the Google Groups >> "MochiKit" group. >> To post to this group, send email to mochikit@googlegroups.com. >> To unsubscribe from this group, send email to >> mochikit+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/mochikit?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochikit@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Is MochiKit Dead?
On Sat, Aug 13, 2011 at 11:35 AM, machineghost wrote: > So, given that: > > * There hasn't been a blog post on the website in ... ever (according > to the front of the site; in reality there was a post back in 2008) > * There hasn't been a release since 2008 > * This mailing list gets a post (with no response) once every other > month or so, if that > * MochiKit is less popular than random frameworks I've never heard of > (xajax? what's that?) by a factor of six (http://www.readwriteweb.com/ > hack/2011/08/javascript-framework-popularit.php) > > it really seems like MochiKit is a dead project, or at best a zombie > project. Is that accurate? I mean, obviously people currently using > it aren't going to stop, but is new development, promotion of the > framework, improvement of the website/docs/etc. dead? Zombie sounds about accurate to me, we still use it but it's done what we've needed it to do for quite a few years so we haven't bothered to make any changes to it. We don't have a lot of incentive to encourage other people to use it, especially at this point. If someone is interested in making improvements they're more than welcome to do so, it's all pretty much github based these days so accepting pull requests, adding contributors and updating the site is very easy. -bob -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] MochiKit.I18n -- proposed new module for internationalization
This is pretty cool, something I always imagined that I might do if I
were doing this kind of localization. We've only done en and zh at
Mochi, so haven't needed anything outside of the system format.
On Mon, Jan 10, 2011 at 6:38 PM, Per Cederberg wrote:
> Since I found the MochiKit.Format.formatLocale() function too limited,
> I hacked up a new MochiKit.I18n module:
>
> https://github.com/cederberg/mochikit/blob/i18n/MochiKit/I18n.js
>
> It is backwards compatible and adds locales for most languages on
> earth (data derived from Wikipedia and Google Closure sources). At the
> moment it only contains numeric formatting information, but can be
> extended with currency and datetime formatting information if needed.
>
> My intention is to include this in the default MochiKit 1.4 tree and
> update the MochiKit.Text module to properly support the number
> formatting specified in these locales (some are not currently
> supported).
>
> Please let me know if you have any issues with this.
>
> Cheers,
>
> /Per
>
> PS. Pasting in the source rst docs below to give a clue as to how it
> is supposed to work.
>
>
>
> Name
>
>
> MochiKit.I18n - internationalization, localization and globalization
>
>
> Synopsis
>
>
> ::
>
> assert( locale().decimal == "." );
> assert( locale("sv_SE").decimal == "," );
>
>
> Description
> ===
>
> This module contains numeric localization information for most languages
> and regions on earth. Actual text formatting lives in other modules (such
> as :mochiref:`MochiKit.Text`).
>
>
> Dependencies
>
>
> - :mochiref:`MochiKit.Base`
>
>
> Overview
>
>
> Locale Names
>
> MochiKit uses IETF language codes [1] to identify a locale, e.g.
> ``"en_US"``. The locale database also supports the use of previously
> unknown locale identifiers by creating a new locale based on the
> language code or the default locale. A number of built-in locale
> identifiers are also supported:
>
> +-+-+
> | Language | Description |
> +=+=+
> | ``system`` | The built-in system locale. It is identical to a |
> | | ``"en_US"`` locale for backward compatibility. |
> +-+-+
> | ``user`` | The user locale, as reported by the browser. This |
> | | points to a specific language locale (or the |
> | | ``"system"`` locale.) |
> +-+-+
> | ``default`` | The default locale, used when no language code is |
> | | provided. This points to the ``"system"`` locale by |
> | | default. |
> +-+-+
>
> The default locale is modified by accessing the ``MochiKit.I18n.LOCALE``
> cache of resolved locale objects:
>
> ::
>
> MochiKit.I18n.LOCALE["default"] = locale("user");
>
>
> Locale Objects
> --
>
> The locale objects returned by :mochiref:`locale()` and stored in the
> ``MochiKit.I18n.LOCALE`` cache all have the following properties (some
> inherited through the prototype chain):
>
> +-+-+
> | Name | Description |
> +=+=+
> | ``decimal`` | The decimal dot character. |
> +-+-+
> | ``separator`` | The thousands grouping character. |
> +-+-+
> | ``separatorGroups`` | The size of thousands groups (from |
> | | right to left). Repeats when exhausted. |
> +-+-+
> | ``percent`` | The percent character. |
> +-+-+
> | ``permille`` | The permille character. |
> +-+-+
> | ``plus`` | The plus sign character. |
> +-+-+
> | ``minus`` | The minus sign character. |
> +-+-+
> | ``signAtEnd`` | The boolean sign at end of string flag. |
> +-+-+
> | ``infinity`` | The infinity character. |
> +--
Re: [mochikit] Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)
That said, I think jQuery Live style functionality is useful, and I
certainly wouldn't mind seeing some additional module to support it.
However, all existing MochiKit functionality works only on the current
state of the DOM and it is not a bug that it doesn't consider future
changes to the DOM that may match the id or selector given.
On Sat, Dec 4, 2010 at 5:58 PM, Per Cederberg wrote:
> Thanks for your input to the project, but I don't think we can
> consider this a bug. Referring to objects that do not yet exist is an
> error in almost any programming language, so it is to be expected. The
> MochiKit docs do not explicitly make it clear that the id lookup is
> immediate, but they definitely do not discuss any lazy or delayed
> lookup of the signal source. The documentation is explicit regarding
> that the destination slot will be looked up on the first signal,
> though.
>
> In your case, why wouldn't you just attach the signal when creating
> the element? Otherwise you'd have to listen to any DOM modification
> and possibly attach signals to elements added. And that use case
> sounds pretty specific to me.
>
> BTW. If you'd like to contribute patches to the MochiKit project, it
> would be much easier if you forked the project on GitHub I think. The
> move happened quite recently, so I haven't moved all my own patches
> yet, but by forking on GitHub it becomes much easier for us
> maintainers to pick up patches and ideas.
>
> Cheers,
>
> /Per
>
> On Fri, Dec 3, 2010 at 16:37, ryanwil...@gmail.com
> wrote:
>> Hi all,
>>
>> I was playing around with MochiKit.Signal, specifically asking the
>> question: "Can I use MochiKit.Signal.connect to set event handlers for
>> objects that don't exist yet.
>>
>> Like so:
>>
>>
>> // connect to our make a new button button
>> MochiKit.Signal.connect("button_that_exists", 'onclick',
>> function(evt ) {
>> var new_button = MochiKit.DOM.BUTTON({'id':
>> "newly_created_button"}, "Hello world, I'm new");
>>
>> MochiKit.DOM.appendChildNodes( MochiKit.DOM.getElement("main_content_div"),
>> new_button );
>> });
>>
>> MochiKit.Signal.connect("newly_created_button", 'onclick',
>> function(evt) {
>> alert("hey world");
>>
>> });
>>
>>
>> NOTE that "newly_created_button" won't exist until the user clicks the
>> "button_that_exists".
>>
>> When I try this I get an error in MochiKit.Signal, about src being
>> null.
>>
>> Is this a bug ("MochiKit.Signal should allow connecting to DOM objects
>> that don't exist yet"), or a limitation of how MochiKit.Signal was
>> designed ("MochiKit.Signal.connect supports only objects that live on
>> the DOM when it is called")?
>>
>> I do see that MochiKit.Signal.signal DOES seem to support the src
>> object being a string, so I suspect the former answer.
>>
>> If it is the former answer (if this error is a bug) I can try to put
>> together a patch to try and allow this behavior, BUT I wanted to check
>> before I went down this road.
>>
>> To see my full example, I've pushed it up to Bitbucket (as part of a
>> "learning" repository, so there's a lot of extra stuff in there :( ):
>> > signals_and_slots/>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "MochiKit" group.
>> To post to this group, send email to mochi...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> mochikit+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/mochikit?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MochiKit" group.
> To post to this group, send email to mochi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mochikit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mochikit?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: Iter: __iterable__ support?
If I remember correctly the problem is that __iterator__ was defined on Object.prototype (to iterate over keys), so everything had it, and it made the registry worthless. Maybe if we moved that code to after the registry, or maybe checked to see if iterator.__iterator__ !== Object.prototype.__iterator__ before the registry, and then just a regular check after. It looks like they moved that behavior to Iterator though, so maybe it's ok to bring back. On Sun, Nov 21, 2010 at 7:55 AM, Fredrik wrote: > FYI, here the actual links to the changes: > > adding __iterator__: > https://github.com/mochi/mochikit/blob/b54de3b0429396cb86edd2c1ade0860831b65379/MochiKit/Iter.js > .. dropping __iterator_: > https://github.com/mochi/mochikit/blob/3022d8755cf932a9581f0ba19134472a368c6d64/MochiKit/Iter.js > > On Nov 21, 12:51 am, Fredrik wrote: >> Hi. >> >> In Iter.js I find this, regarding the support for the __iterator__ >> pattern. >> >> //--- >> // XXX: We can't support JavaScript 1.7 __iterator__ directly >> // because of Object.prototype.__iterator__ >> //--- >> >> In Git/SVN the only message to the (reverted) change (2006-05-18) is >> "oops" :) >> >> The Google Closure library seems to sniff for it for example, >> see:http://closure-library.googlecode.com/svn/docs/closure_goog_iter_iter... >> >> Is this still applicable? Supporting __iterable__ would be very useful >> I'd say. >> .. Guess this more or less a question for Bob himself but if anyone >> has knowledge about this issue please enlighten! >> >> Regards >> // Fredrik Blomqvist > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Code comments in MochiKit sources
It was for Aptana, not sure if anyone still cares? On Tuesday, October 12, 2010, Per Cederberg wrote: > Does anyone (Bob?) know why the MochiKit source code has these types > of comments for most exported functions: > > /** @id MochiKit.Signal.connect */ > > Cheers, > > /Per > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] MochiKit moving to github
I'm in the process of moving MochiKit to github to remove the maintenance burden from the Mochi ops team, and make it easier to contribute. We're in the process of switching everything to git internally anyway, so it's about time: http://github.com/mochi/mochikit I think that we'll just go ahead and use github pages for the site once the transition is complete. I have most of it set up here (the customize functionality still uses SVN): http://mochi.github.com/mochikit We haven't migrated anything in Trac yet. I'm not sure how much of it is really useful these days. -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: SpiderMonkey and MockDOM Issues
MochiKit provides MockDOM so that some tests can be run without a full
browser environment. It does not exist for server-side programming
purposes, it was built before that was a really sensible thing to do.
On Thu, Oct 7, 2010 at 9:21 PM, Kaleb Hornsby wrote:
> Since MochiKit makes JavaScript a more robust programming language, I
> am trying to use both to do some server side programming. That's why
> MochiKit provides a MockDOM. I think that overall, it should not be
> coupled to the DOM at all.
>
> On Oct 7, 7:54 am, Bob Ippolito wrote:
>> No idea what you're trying to do but it sounds like whoever packaged
>> this with Ubuntu did the wrong thing.
>>
>> Surely there must be an up to date mirror of mochikit on github or
>> something that can be used until service is restored.
>>
>>
>>
>> On Thu, Oct 7, 2010 at 1:25 AM, Kaleb Hornsby wrote:
>> > I am running Ubuntu and have just discovered MochiKit in the
>> > repositories. I attempted to start it with smjs, but I ran into an
>> > error. I apparently needed MochiKit.MockDOM. I found it [online] [1]
>> > on another site than mochikit's because their track server is down.
>> > This seemed rather old. Sure enough, though, I loaded mockdom.js and
>> > then loaded mochikit.js and it solved the error, but created another.
>>
>> > Sample output:
>>
>> > $ js
>> > js> load('MochiKit.js')
>> > MochiKit.js:3506: TypeError: this._document has no properties
>> > js> load('MockDOM.js')
>> > js> load('MochiKit.js')
>> > MochiKit.js:4323: ReferenceError: navigator is not defined
>> > js>
>>
>> > Does somebody have a more recent version of mockdom that works with
>> > mochikit?
>>
>> > [1]:http://bknr.net/trac/browser/trunk/projects/quickhoney/website/static...
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "MochiKit" group.
>> > To post to this group, send email to mochi...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > mochikit+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/mochikit?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "MochiKit" group.
> To post to this group, send email to mochi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mochikit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mochikit?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] SpiderMonkey and MockDOM Issues
No idea what you're trying to do but it sounds like whoever packaged
this with Ubuntu did the wrong thing.
Surely there must be an up to date mirror of mochikit on github or
something that can be used until service is restored.
On Thu, Oct 7, 2010 at 1:25 AM, Kaleb Hornsby wrote:
> I am running Ubuntu and have just discovered MochiKit in the
> repositories. I attempted to start it with smjs, but I ran into an
> error. I apparently needed MochiKit.MockDOM. I found it [online] [1]
> on another site than mochikit's because their track server is down.
> This seemed rather old. Sure enough, though, I loaded mockdom.js and
> then loaded mochikit.js and it solved the error, but created another.
>
> Sample output:
>
> $ js
> js> load('MochiKit.js')
> MochiKit.js:3506: TypeError: this._document has no properties
> js> load('MockDOM.js')
> js> load('MochiKit.js')
> MochiKit.js:4323: ReferenceError: navigator is not defined
> js>
>
> Does somebody have a more recent version of mockdom that works with
> mochikit?
>
> [1]:
> http://bknr.net/trac/browser/trunk/projects/quickhoney/website/static/MochiKit/MockDOM.js?rev=2828
>
> --
> You received this message because you are subscribed to the Google Groups
> "MochiKit" group.
> To post to this group, send email to mochi...@googlegroups.com.
> To unsubscribe from this group, send email to
> mochikit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mochikit?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] svn.mochikit.com and trac.mochikit.com down
It looks like the ops team at Mochi has decommissioned the machine it runs on without realizing that services were still hosted there. I've filed a ticket to get these services back up, hopefully they haven't destroyed it entirely. On Thu, Oct 7, 2010 at 1:20 AM, Ethan Jucovy wrote: > Hi, > > I noticed yesterday that http://svn.mochikit.com and http://trac.mochikit.com > are down. They seem to still be down today. > > http://downforeveryoneorjustme.com/svn.mochikit.com > > Has the mochikit repository moved somewhere else? > > Thanks, > Ethan > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Mochikit.js does not download from Apache 2.2.3 on Centos 5.4/5.5
That's strange, I'm not seeing any problem with Firefox or Chrome on Mac. On Wed, Jun 9, 2010 at 11:42 AM, jonauman wrote: > The file hangs at 8% download using curl. However, if I copy the > javascript to a Mac server and I can download the file. > > I am not able to access http://mochikit.com via Firefox or curl on my > Mac with Snow Leopard. I am able to do so in Safari on my Mac. > > jonauman:~ jonauman$ curl -O > http://www.mochikit.com/include/_js/MochiKit/MochiKit.js > % Total % Received % Xferd Average Speed Time Time > Time Current > Dload Upload Total Spent > Left Speed > 11 110k 11 13376 0 0 551 0 0:03:25 0:00:24 > 0:03:01 0 > > As you see, it hangs at 11% > > It was working a few days ago, and stopped working yesterday. Any > ideas? > > -Jon > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Additional information for a bug
Well, the implementation of MochiKit's keys function was written years before any of the browsers implemented an Object.keys function. It's unfortunate that they don't do exactly the same thing, but changing the implementation of MochiKit's keys would break existing code. On Mon, Apr 26, 2010 at 7:46 PM, Saikat Chakrabarti wrote: > I couldn't find a way to comment on a bug I just filed (https:// > trac.mochikit.com/ticket/365) but here is a sample implementation that > would do the correct thing: http://gist.github.com/380263 (from > http://ejohn.org/blog/ecmascript-5-objects-and-properties/). > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Providing patch for ticket #361
You can send it here to the list On Thu, Feb 18, 2010 at 3:18 AM, niek.kouwenb...@gmail.com wrote: > Hi, > > I've just created a ticket for which I have a patch. Since editing and > replying to tickets seems to be disabled since 2008, I have no way of > attaching this patch. > > Since I've been using MochiKit quite some time now in several > projects, I am keen on helping a little with development (which seems > rather slow). Not being able to provide patches or comment to tickets > seems to make this really hard and might kill MochiKit future. > > Where do I send my patch? > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To post to this group, send email to mochi...@googlegroups.com. > To unsubscribe from this group, send email to > mochikit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mochikit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] JSON.parse & MochiKit.Base.evalJSON
On Sat, Nov 28, 2009 at 2:18 PM, Per Cederberg wrote: > I just tried to modify MochiKit.Base.evalJSON() to use the new > JSON.parse() function when available. This would give us the following > advantages: > > 1. Speed (but, well... eval() is probably fast enough already) > 2. Security > > Unfortunately we would also get a nasty regression issue due to the > stricter syntax enforcement in JSON.parse() vs. eval(). None of the apps we've written depend on the capability to parse invalid JSON, so it wouldn't bother me. -bob -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
At least with recent browsers there are better ways to speed this up,
e.g. by leveraging more native code (getElementsByClassName and/or
XPath). None of them did this when the code was written in 2005 but I
think all of them do now (except maybe IE).
On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg wrote:
>
> Generally, I think some of these optimizations make sense. Like using
> "===" instead of "==" in code like this:
>
> typeof(x) === "string"
>
> But I think the optimizations where variables are moved outside code
> blocks and where array lengths are stored to variables should be used
> with extreme caution. These are the type of things that people used to
> recommend for Java code, but nowadays the virtual machines optimize
> these things better by themselves. And what used to be a speedup
> actually often leads to decreased performance.
>
> For JavaScript, the VM:s are much more immature. But they are rapidly
> becoming faster and more advanced. So low-level code optimizations
> that result in a speedup today, might not do so just a year or two
> down the road.
>
> I think our focus here should be on clarity of intention. If some
> critical-path function is extremely slow, we might want to have a look
> at optimizing that specific function. But in general I think we should
> refrain from low-level code optimizations that doesn't also improve
> code readabilty and reduce the frequency of bugs.
>
> Also, if speed is a problem, most serious speedups come from changes
> to the algorithms and data structures involved. In this case for
> instance, it might be faster to first find elements by class and then
> filter out the ones with the correct tag. Or by using an
> indexOf("class") on the className field before splitting it up. These
> kind of optimizations will probably result in higher gains with less
> reduction to the code readability.
>
> Just my 2 cents.
>
> Cheers,
>
> /Per
>
> On Tue, Nov 3, 2009 at 23:23, takashi mizohata wrote:
>> Hi All,
>>
>> Forgive me, if this is a recurring argument.
>>
>> Today I was looking at Firebug profiler and I realize that
>> getElementsByTagAndClassName takes certain percentages of processing
>> time. And I took a look at the code, and I did a little bit of hand
>> optimization. It doesn't change any semantics of code, but just
>> organizing code. It does pass the tests of course. And i got around
>> 6% better performance.
>>
>> Well the down side of this tweak may be the decrease of readability.
>> Since you need to carefully type comma between local variables. I
>> usually check it with jslint before commit in order to find those
>> potential mistakes. And obviously I don't much about coding
>> convention of MochiKit and I might need to edit the style of it.
>>
>> Here I attached .patch file for this issue. Please try it and let me
>> know what you think. if somebody's interested in, I can contribute
>> some more performance tweaks in MochiKit.
>>
>> Thanks,
>>
>> --
>> Takashi M
>>
>> >
>>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Base.js unescape reassignment and intrusion protection systems
There are various ways it could be rewritten, but without knowing exactly how stupid the IPS is it's hard to say which permutation would pass its test. Someone who can reproduce this issue should spend some time with it and produce a patch. On Thu, Jul 16, 2009 at 6:34 PM, Michael wrote: > > I have found a problem with MochiKit Base.js and the intrusion > protection system at work. The IPS truncates Base.js because it > assigns the unescape() function to a variable (in parseQueryString(), > line 1225 in version 1.4.2 of Base.js). The IPS response is documented > here: > > http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm > > Has anybody else seen this behaviour? Could the code be re-written to > not use that reassignment? > > > (I discovered this because MarkMail does not work, and it uses a > compressed version of MochiKit 1.4.) > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Mapi function
Did you read the sentence that I wrote? izip(count(), someArray) does the indexes. On Wed, May 20, 2009 at 7:32 AM, Rupert Bates wrote: > > Thanks for the reply, so that answers the alternate rows case, but > there are plenty of other cases where you would want to know the index > of the item. The items() solution feels like a bit of a workaround and > presumably has performance implications. Would a mapi function not be > more efficient and elegant? Sorry if I'm missing something. > Rupert > > On May 19, 4:13 pm, Bob Ippolito wrote: >> Typically this is done with count or cycle and izip. >> >> izip(cycle(["odd", "even"]), someArray) >> >> On Tue, May 19, 2009 at 2:19 AM, Rupert Bates wrote: >> >> > Hi there, how about adding a mapi function to Mochikit.Iter which >> > passes the index of the item being processed to the specified >> > function? It would be really handy, for instance for specifying >> > altenate rows on a table. >> > Rupert >> >> > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Mapi function
Typically this is done with count or cycle and izip. izip(cycle(["odd", "even"]), someArray) On Tue, May 19, 2009 at 2:19 AM, Rupert Bates wrote: > > Hi there, how about adding a mapi function to Mochikit.Iter which > passes the index of the item being processed to the specified > function? It would be really handy, for instance for specifying > altenate rows on a table. > Rupert > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Question about Color.fromString
Don't use "new".
On Sun, Apr 19, 2009 at 7:04 AM, Zak wrote:
>
> I can't get a null result from the fromString method. No matter what
> I put in, it's never null. Generally, what I'm expecting it to do is
> if I pass in a value that's not hex, not hsl, not rgb, that it should
> drop through to the namedColor check and when it doesn't find the
> named color, it should return null. But this just never seems to
> happen.
>
> Also, it looks like there's not much validation once it's determined
> that a color starts with #, rgb or hsl, not too worried about this as
> I'll be checking my inputs before creating the color object, but is
> this by design?
>
> Here's a short example:
>
> createLoggingPane(true);
>
> var myColor = new Color.fromString("xyz");
> log(myColor == null);
>
> ^^^
>
> This always returns false for me, no matter what I put in the
> constructor. Perhaps there's something wrong with my code? Here's
> what I'm actually doing with it so far:
>
> function findColorsClick(text) {
> createLoggingPane(true);
>
> var myColor = new Color.fromString("123lksdjf098234lkj");
>
> if (myColor){
> var colorNameHash = Color.namedColors();
> var myColorName = "[No color name found]";
> for (var i in colorNameHash)
> {
> if (myColor.toHexString() == colorNameHash[i]){
> myColorName = i;
> break;
> }
> }
> alert("Color Name: " + myColorName + "\nRGB: " + myColor.toRGBString
> () + "\nHSL: " + myColor.toHSLString() + "\nHEX: " +
> myColor.toHexString() + "\nIs light: " + myColor.isLight() + "\nIs
> dark: " + myColor.isDark());
> }
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: doSimpleXMLHttpRequest, IE and non ascii characters
You probably need to use encodeURIComponent.
2009/4/16 Boštjan Jerko :
>
> Hi!
>
> I am using MochiKit 1.4 and have a simple usage of
> doSimpleXMLHttpRequest:
>
> var handleServerFeedback = function(result)
> {
> log(d_querystring);
>
> }
>
> var handleServerError = function()
> {
> log("error");
>
> }
>
> returnedServerValue = new doSimpleXMLHttpRequest("/
> showContent/?f_name="+d_querystring);
> log(d_querystring);
>
> returnedServerValue
> .addCallbacks(handleServerFeedback,handleServerError);
>
>
> When I use the script on any browser it works perfectly, but when I
> set d_querystring with some non standard text characters or non ascii
> characters it doesn't work on Internet Explorer - it works in Firefox.
>
> I did a RSS reader and when I have a feed caled: Avian’s Blog it
> doesn't work. Mind that there is a ` character in the name. The
> problem also appears when I use some Slovene characters (e.g. ccaron -
> č).
>
>
> Any ideas why is this happening?
>
>
> B.
>
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: why use MochiKit.Base.update to create the mochikit object hierarchy?
The reason I chose not to hide methods in a scope is so that you could
monkeypatch them if you needed to. In retrospect I probably should've
just done it in a scope because it would make the code smaller. Using
an object literal was the compromise I chose between assigning each
property by themselves and using a closure.
On Sun, Mar 29, 2009 at 11:56 AM, Per Cederberg wrote:
>
> I think Bob is the best person to answer this, but in the current
> version of the code "MochiKit.DOM", "MochiKit.Style" and friends are
> all created by the MochiKit.Base._module function. This function
> automatically inserts a few practical helpers, such as the module
> name, __repr__() and toString(). So by using a call to update(), these
> generated helper properties are kept intact.
>
> An alternative would of course be to assign each property by itself:
>
> MochiKit.DOM.currentWindow = ...
> MochiKit.DOM.currentDocument = ...
>
> But I think people would consider this too verbose. I don't mind
> myself though, because I think it would increase the code clarity
> somewhat.
>
> Anyway. The "correct" way of doing a library nowadays I think is this:
>
> (function(scope) {
> ... declare stuff ...
> ... export selected resources into 'scope.MochiKit.DOM' ...
> })(this);
>
> That would hide internal methods securely inside an inner scope. But
> sometimes the internal methods are quite handy of course...
>
> Cheers,
>
> /Per
>
> On Sun, Mar 29, 2009 at 3:26 PM, Freek Zindel wrote:
>>
>> When looking at the source code for MochiKit I found that the object
>> hierarchy is created with calls to update. e.g.:
>> MochiKit.Base.update(MochiKit.Dom,{...});
>>
>> I am eager to learn about the rationale for doing this so that I may
>> enhance my understanding of javascript.
>>
>> What is the advantage of using this technique over an assignment such
>> as:
>> MochiKit.Dom = {...}
>>
>> I am aware of the benefit of having the option to call update several
>> times, each time adding some extra functionality to an object. But if
>> only one call to update is made for a specific part of the MochiKit
>> tree wouldn't the work that update does just be extra overhead?
>>
>> Or are there other benefits?
>>
>> Best regards,
>>
>> Freek Zindel
>>
>> >
>>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Defered.setFinal
Finalizing a Deferred should ensure that no further callback/errbacks
are registered and it should attach a default error handler (success
should be no-op). The most common problem I've seen with Deferreds is
that an error occurs but nobody attached an error handler that far
down the stack. In Python they work around this by having a finalizer
so that you see the error when the object gets GC'ed, but that's not
really possible in JS since you don't have finalizers or weak
references.
On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg wrote:
>
> I think this is a good idea. I needed something similar too, so I
> ended up writing an ugly hack that worked most of the time...
>
>d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
>
> It adds new callback once the first deferred result drops in,
> hopefully after all the other callbacks have been added...
>
> But a more formally correct solution would probably be a good idea.
>
> Cheers,
>
> /Per
>
> On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara
> wrote:
>> Hi Per,
>>
>> I have just started again improving the MochiKit Extensions. While
>> creating tests for the Ajax module, I found one problem (not bug, but
>> specific to the feature I'm trying to implement). I registered a
>> callback which should be fired at the end of all registered callbacks.
>>
>> I achieved by modifying Async.js with a new method `setFinal` (not
>> addFinal as there should be only one finalizer) which gets fired when
>> `chain.length == 0`. It's simple. I would we happy if you add one such
>> function in MochiKit.Async.Defered...
>>
>> Regards
>> --
>> Amit
>>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Curry and uncurry
The difference between currying and partial application is that you
can call a curried function f with 1 argument that needs N arguments
and the return value is a function f_1 that needs N-1 arguments and
when called again with 1 argument will return a function f_2 that
takes N-2 arguments, etc. until some point where N-K=0 and it returns
a value instead of another function.
It's effectively a transform that wraps a function f(a, b, c) with
something like this:
function (a) { return function (b) { return function (c) { return f(a,
b, c); } } }
Partial application explicitly takes a function with N arguments and
returns a function that takes N-K arguments but the resulting function
behaves the same as any other function in JS without that "magic".
I'm not a real big fan of currying in languages where it's not
built-in. It's easy to make a mistake by calling a function with too
few arguments and you get a harder to track down bug. It also doesn't
work well with languages that have default arguments or the equivalent
(e.g. using the arguments object) because you don't know exactly when
to stop currying.
On Wed, Dec 17, 2008 at 11:31 PM, Per Cederberg wrote:
>
> The names "curry" and "uncurry" were a bit confusing to me, so it took
> me a while to understand these two functions...
>
>http://en.wikipedia.org/wiki/Currying
>
> To me (and probably other non-Haskell users) the names imply the same
> thing as bind or partial. It's a confusing world... :-(
>
> In JavaScript, I think plain apply + MochiKit.Base.bind does the same thing:
>
>var test = [ [10, 1], [20, 2], [30, 3] ];
>var addArray = bind("apply", operator.add, null);
>assertEqual(map(addArray, test), [11, 22, 33]);
>
> It's no beauty, so perhaps this particular variant of bind merits an
> alias? Uncurrying is just the same as the built-in apply function, so
> that seems unnecessary.
>
> Cheers,
>
> /Per
>
> On Wed, Dec 17, 2008 at 5:22 PM, Arnar Birgisson wrote:
>>
>> One thing I think could be useful is to port Haskell's curry and
>> uncurry. This is basically a convenience method for (un)wrapping an
>> .apply on a function object:
>>
>> function curry(f) {
>>return function () {
>>// first convert arguments to a regular array
>>var args = Array.prototype.slice.call(arguments);
>>return f(args);
>>}
>> }
>>
>> function uncurry(f) {
>>return function (args) {
>>return f.apply(this, args);
>>}
>> }
>>
>> Example use:
>> test = [ [10, 1],
>> [20, 2],
>> [30, 3] ];
>>
>> assertEqual(map(uncurry(operator.plus), test), [11, 22, 33]);
>>
>> // assume join is a function that takes a list and returns a string
>> // with the elements joined with some delimiter
>>
>> f = curry(partial(join, _, ", "))
>> assert(f("Bond", "James Bond") == "Bond, James Bond")
>>
>> Does anyone else think this could be useful? What module would it fit?
>> Base already has a lot of functional stuff (compose, partial, map &
>> friends) - I'm wondering if it fits there or if all the functional
>> stuff should be in a seperate module MochiKit.Functional - as Python
>> seems to be heading.
>>
>> cheers,
>> Arnar
>>
>> >
>>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: connectEach shortcut
On Fri, Dec 12, 2008 at 11:20 AM, Arnar Birgisson wrote:
>
> Hi
>
> On 12.12.2008, at 16:45, Eoghan wrote:
>>connectEach($$('#my-ul li'), 'onclick', function(e){
>>// do sumn'
>> });
>>
>> rather than slightly more unwieldy:
>>forEach($$('#my-ul li'), function(el){
>>connect(el, 'onclick', function(e){
>>// do sumn'
>>});
>> });
>>
>> Is it a good candidate to include in the signal api?
>
> I can definitely see the use case, but IMO this is one of the cases
> where I'd not want to add since forEach is not that much typing. In my
> mind this the whole point of having a functional, composable API such
> as the iter module.
>
> Just my 2000 ISK
Personally I think it's useful, but I would rather have the connect
take a selector as a string instead of a list. Makes it much easier to
track down when the lookup happens in-connect.
connectAll("#my-ul li", "onclick", ...);
(not sold on the name)
We could even have the existing API do this if passed a list, but
perhaps that's a bit too magical.
connect(["#my-ul li"], "onclick", ...);
The other problem is that the return signature has to change for
disconnect, or we have to allow for a different kind of disconnect.
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Problems with appendChildNodes?
It looks like you also need Iter.js after Base.js and before DOM.js in
order for that to work properly. Not entirely sure why without looking
deeper into it, but I think that's a bug.
On Wed, Nov 26, 2008 at 2:31 AM, Bjoern <[EMAIL PROTECTED]> wrote:
>
> Thanks! This fails for me, using Firefox 3.0.4 on Ubuntu 8.10:
>
>
> www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> http://www.w3.org/1999/xhtml"; lang="de" xml:lang="de">
>
> Mochitest
>
>
>
>
>function init(){
>appendChildNodes("test", SPAN({}));
>}
>
>addLoadEvent(init);
>
>
>
>
>Mochikit Test
>Random text...
>
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Problems with appendChildNodes?
Are you adding SPAN({}) to a string or something?
appendChildNodes("idOfADiv", SPAN({})) should insert an empty SPAN,
but appendChildNodes("idOfADiv", SPAN({}) + "") might have the
behavior that you're describing. You want to use commas, not addition
to add multiple nodes, e.g. appendChildNodes("idOfADiv", SPAN({}),
"text", DIV({}))
Using $() is not necessary because any function that expects a DOM
node will automatically do the getElement for you.
On Tue, Nov 25, 2008 at 2:24 PM, Bjoern <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I am new to MochiKit and couldn't get appendChildNodes to work
> properly. As an example, I tried
>
> appendChildNodes($("idOfADiv"), SPAN({}));
>
> but on the website this shows up as [object HTMLSpanElement] (same
> with images, created with IMG), so it doesn't look as if a span dom
> object is being inserted.
>
> What am I doing wrong?
>
> Björn
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Suggested API:s for MochiKit 1.5
On Mon, Oct 27, 2008 at 1:49 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > Development of MochiKit 1.5 is about to start. But before we open the > flood-gates, it might be useful to have a look at a summary of all > proposed API:s. Below you'll find a comprehensive list of all API > additions that I've found (so far). > I'd like to have an onDOMReady event and change addLoadEvent to use that, basically a subset of the facilities available in YUI: http://developer.yahoo.com/yui/examples/event/event-timing.html (haven't made any associated tickets yet) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit 1.4.1 released
I don't think anything relevant to the screencast has changed, although there are a lot of new things that one could talk about in a new screencast. I suppose it was probably a bad idea to associate the screencast with a version number. On Sun, Nov 2, 2008 at 12:43 PM, Cowmix <[EMAIL PROTECTED]> wrote: > > With the new release(s) of Mochikit in the past few weeks... do you > think it might be appropriate to update the 1.1 based screen cast? > > Thanks! > > On Nov 2, 6:09 am, "Per Cederberg" <[EMAIL PROTECTED]> wrote: >> MochiKit 1.4.1 has now been released and is available on the web site: >> >>http://mochikit.com/download.html >> >> This version contains the correction of a few issues found since the >> original 1.4 release: > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
If you need some server-side code that echos back the content with Content-Disposition set appropriately, you can put it in the google app engine project that I built to fetch the blog and mailing list feeds. Just let me know once the code is there and I'll update it. http://svn.mochikit.com/mochikit.com/trunk/mochikit-dot-com/ -bob On Wed, Oct 22, 2008 at 7:27 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Often, ignoring a problem eventually causes a solution to appear. So > the other day it just struck me that all we need to do, to enable > configurable packing, is to parse the packed version into modules. And > then allow the user to paste them back together. > > So I developed a new demo that does that. Now it uses only a packed > version of MochiKit which it downloads as text and analyzes for > dependencies. Then creates the corresponding UI. > >http://www.percederberg.net/mochikit/pack.html > > As the standard packed version of MochiKit doesn't include DragAndDrop > and Sortable, I also included those in my source packed version. > > The actual download button is still work-in-progress at this point. > Only works in Firefox and even then just sort-of-works. Will have to > ponder that a bit more before creating a final version. > > Cheers, > > /Per > > On Mon, Oct 13, 2008 at 11:33 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >> Hi again, >> >> On Mon, Oct 13, 2008 at 22:23, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >>> Although, there is one outrageous possibility: We could pregenerate >>> all possible combinations of modules. Now, before you call me crazy, >>> note that even if 14 modules could potentially mean 2^14~=16k >>> different combinations, the dependency graph puts severe restrictions >>> on that. So for fun, I decided to see how many there really are. Given >>> the dependency specs Per used in the above html file, there are >>> exactly 1952 possible combinations such that all dependencies are >>> included :D >> >> While I should probably point out that my last message was >> tongue-in-cheek, there was also a glaring bug in my algorithm. After >> fixing that and rerunning, the possible combinations are *merely* 817 >> :) >> >> The correct code will appear on my blog in a few minutes. >> http://www.hvergi.net/ >> >> cheers, >> Arnar >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit 1.4 released
Awesome! Thanks for all the hard work everyone, I owe many of you beers :) On Tue, Oct 21, 2008 at 9:35 AM, Jason Bunting <[EMAIL PROTECTED]> wrote: > > Congrats and thanks to everyone involved for all of the hard work that goes > into maintaining this stable toolkit! > > Jason Bunting > >> -Original Message- >> From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On >> Behalf Of Per Cederberg >> Sent: Tuesday, October 21, 2008 4:32 AM >> To: MochiKit >> Subject: [mochikit] MochiKit 1.4 released >> >> >> MochiKit 1.4 has now been released and is available on the web site: >> >> http://mochikit.com/download.html >> >> The full change history from version 1.3.1 is rather lengthy, but you >> can find it on our web site: >> >> http://mochikit.com/doc/html/MochiKit/index.html#version-history >> >> As far as I know, there should be no backwards-incompatible API >> changes between 1.3.1 and 1.4. If you happen to find one, please let >> us know through this mailing list so that we can update the docs >> and/or fix the issues. >> >> Finally, many thanks to everyone who contributed code, documentation, >> bug reports, ideas and everything else during this long development >> cycle. Looking forward to hear from you all during the 1.5 >> development. >> >> Cheers, >> >> /Per >> >> > >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.175 / Virus Database: 270.8.2/1737 - Release Date: 10/21/2008 >> 9:10 AM > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.isChildNode and isParent
I don't see any direct references to either isParent or isChildNode in
any of our code here at Mochi, so I don't care ;)
-bob
On Sat, Oct 18, 2008 at 9:42 AM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
> Attempting two answers in one below...
>
> On Sat, Oct 18, 2008 at 12:23 AM, Jason Bunting
> <[EMAIL PROTECTED]> wrote:
>> Who is Noone? :P
>
> Sigh... The endless joys we bring you native English speakers... ;-)
>
> On Sat, Oct 18, 2008 at 5:54 PM, Christoph Zwerschke <[EMAIL PROTECTED]>
> wrote:
>> Hm, if I read the code correctly, then there is another difference,
>> namely that isChildNode also returns true if the second node is not the
>> direct parent, but also for grandparents and any ancestors. So it should
>> be actually renamed to something like isDescendant or isAncestor.
>
> Both actually do that. But isParent() does it through recursion
> instead of iteration:
>
>isParent: function (child, element) {
>var self = MochiKit.DOM;
>if (typeof(child) == "string") {
>child = self.getElement(child);
>}
>if (typeof(element) == "string") {
>element = self.getElement(element);
>}
>if (child == null || element == null) {
>return false;
>} else if (!child.parentNode || child == element) {
>return false;
>} else if (child.parentNode == element) {
>return true;
>} else {
>return self.isParent(child.parentNode, element);
>}
>},
>
> I totally agree on the naming. Should be named as you propose, but I
> don't see us changing the API right now though... :-(
>
> Cheers,
>
> /Per
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Well clearly we have a place where all of that can happen - the mailing list :P On Tue, Oct 14, 2008 at 12:51 AM, Amit Mendapara <[EMAIL PROTECTED]> wrote: > > Whatever you prefer Bob. But users who want to contribute by means of > codding, reporting/fixing bugs, suggesting new ideas or anything > should never been restricted anyway because of those few spammers... > > - Amit Mendapara > > On Oct 13, 8:19 pm, "Bob Ippolito" <[EMAIL PROTECTED]> wrote: >> Well, the login database is outside of trac since we're using basic >> auth to login and they are the same credentials that give svn commit >> access. Disabling anonymous commenting is something that I did because >> I couldn't be bothered to implement a better spam filter or maintain >> it. >> >> I'm not really sold on launchpad, I think bzr would be too much of a >> barrier to entry for many people. I would certainly consider moving to >> google code though, because that would be easy enough. All of our >> other open source projects are there these days. People that want to >> use distributed vcs to keep a local branch can do so easily enough >> with a central svn repo. >> >> On Mon, Oct 13, 2008 at 6:47 AM, Amit Mendapara >> >> <[EMAIL PROTECTED]> wrote: >> >> > The version of trac is okay. >> > Seehttp://trac.edgewall.org/wiki/TracPermissions, >> > you can easily prevent those spams. You can see how TurboGears trac is >> > configured... >> >> > You can also think about moving MochiKit to Launchpad.net. It's really >> > a good platform to host OpenSource projects with distributed vcs, bug >> > tracking, blueprints and more. Launchpad team has already created a >> > project for MochiKit (so that no one then MochiKit team can claim the >> > ownership, you can contact Launchpad team to get ownership rights). >> >> > - Amit Mendapara >> >> > On Oct 13, 6:24 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote: >> >> On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara >> >> >> <[EMAIL PROTECTED]> wrote: >> >> > Once, I filed a bug report on the trac (related to Sortables), but I >> >> > was unable to change/comment it later. That's why I never submitted >> >> > again. >> >> >> Yes, this is very unfortunate. I used to have the same problem, so I >> >> hear you loud and clear. >> >> >> The problem is the amount of spam that we'd otherwise receive in bug >> >> reports. Don't know if there is some newer version of Trac that fixes >> >> this that we could install on the server. Or if there is some other >> >> solution that would work. Until that happens, emailing to this list or >> >> directly to the bug owner should work. Sorry about that. >> >> >> Cheers, >> >> >> /Per > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Migrate to Google Code?
Keeping the commit hooks for updating the site is possible, I'll probably set up a svn mirror at or near the current svn repository and our internal tools will be able to update that. Might have to hook up some kind of mail hook thing to have it happen "instantly" though, I don't think google code has a HTTP post-commit "web hook". Anyway, I can take care of it. These are the sorts of reasons that I didn't bother before, but I'm willing to do it now :) I do like keeping the packed version and docs in svn, but we could have a process that automatically does it and performs a second commit when necessary (but setting that up might be a little too much work to bother). -bob On Mon, Oct 13, 2008 at 12:02 PM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Google code seems fine by me. Especially if we get better access for > normal users. > > The only issue I come to think of is that the mochikit.com web site > automatically updates from svn trunk. Don't know if it would be easy > to keep that link. Something which is pretty good to have from time to > time. Especially when we are linking to examples and demos that are > actually inside the project repo (not just on the web site). > > On the other hand, we often forget to make_docs.py or pack.py before > committing to svn. So perhaps it would be good to have these steps > performed automatically by some automated web publisher. So that we > wouldn't need the packed version in svn... > > Just my random thoughts. > > Cheers, > > /Per > > On Mon, Oct 13, 2008 at 6:17 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> >> I've been considering this for a while but didn't want to put forth >> the effort at the time, but I think that with the release of 1.4 it >> would be a good time to migrate from the Mochi Media hosted Trac and >> SVN over to something else. My personal preference is Google Code >> because we already use that for our other open source projects and it >> wouldn't require transitioning from a mainstream VC solution to >> something more obscure (e.g. launchpad, github). >> >> Per, do you have any thoughts on this? >> >> -bob >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
AFAIK Flash can't save to disk in that manner either. You can build Flash content with free tools though (Adobe Flex 2 SDK, MTASC, haXe, etc.). -bob On Mon, Oct 13, 2008 at 11:51 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Scary stuff. JS in JS... :-) > > I also gave the download issue some thought. Seems it would be > possible to spoof a download in IE and Firefox (with privilege > escalation warning). But not on Safari. And anyway, it would be an > ugly and messy hack. > > So my next thought would be to create something in Flash that could > save a file locally. We can even supply it with the actual text file > content from JS just like Bob explained. Is that doable? I don't have > a license for that stuff and have never worked in Flash myself, so > perhaps I'm just dead wrong here. > > Third option would be to just open a window with the packed text and > ask the user to do Ctrl-S. Perhaps by setting the window title or > something. > > Cheers, > > /Per > > On Mon, Oct 13, 2008 at 6:29 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> I had intended to build exactly that years ago, but never got around >> to it... mostly because it's hard to do client side and I didn't want >> that feature to be dependent on some server-side script. >> >> My thinking was that we'd keep packed versions of every module (so >> that we could continue to use the Java based packer, instead of >> implementing a JavaScript version)[1] and some client-side could could >> XHR them all down and concatenate them in the correct order, but the >> problem is allowing the user to actually download that text. Using the >> pasteboard would work I guess, but that's not a nice solution. >> >> I suppose we could set something up where the client just does a POST >> to some URL (maybe an app engine service or something) and the server >> simply echos it back with a Content-Disposition header that forces >> download. >> >> [1] But maybe it would be reasonable to write an entirely JS based >> packer with Narcissus >> http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any >> other projects like this that I'm not aware of? >> >> -bob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
I had intended to build exactly that years ago, but never got around to it... mostly because it's hard to do client side and I didn't want that feature to be dependent on some server-side script. My thinking was that we'd keep packed versions of every module (so that we could continue to use the Java based packer, instead of implementing a JavaScript version)[1] and some client-side could could XHR them all down and concatenate them in the correct order, but the problem is allowing the user to actually download that text. Using the pasteboard would work I guess, but that's not a nice solution. I suppose we could set something up where the client just does a POST to some URL (maybe an app engine service or something) and the server simply echos it back with a Content-Disposition header that forces download. [1] But maybe it would be reasonable to write an entirely JS based packer with Narcissus http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any other projects like this that I'm not aware of? -bob On Mon, Oct 13, 2008 at 4:47 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Seeing that this wasn't just an omission, I won't change it for the 1.4 > version. > > For version 1.5 I think we should consider having a nice little > download web page where you can customize your packed version of > MochiKit. I created a little dummy UI to show what I mean: > > http://www.percederberg.net/mochikit/pack.html > > If we plunge forward and start adding more extension modules (as > suggested here before), I think such a UI would be important to keep > all users happy. > > Cheers, > > /Per > > On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >> Hi Per, >> >> On Wed, Oct 8, 2008 at 15:38, Per Cederberg <[EMAIL PROTECTED]> wrote: >>> The packed version of MochiKit still doesn't include the modules >>> DragAndDrop and Sortable. I found a previous discussion of that in >>> this thread: >>> >>> http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 >>> >>> None of the two modules have been much modified lately, so perhaps >>> they are now stable? Otherwise, I think we should make the docs >>> clearer regarding their status and how to use them. >> >> Including them is fine with me, but for my own purposes I don't use >> that.. since for me MochiKit serves purely as a utility library rather >> than one of UI elements. I suspect there are others in a similar >> situation. >> >> What we really should do, and it should not be too hard, is make >> several packed versions. Basically for every module we'd provide a >> "dependency-closed" packed version - i.e. one that includes that >> module and all of its dependencies. Modifying the "packed" script to >> perform this should be doable. >> >> If people don't like the idea of so many packed versions, perhaps we >> could decide on two or three "feature-sets" and provide packed >> versions of these. I know MochiKit is not that big, and download time >> is not really the issue - but bandwidth can be an issue for the host. >> >> cheers, >> Arnar >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Migrate to Google Code?
I've been considering this for a while but didn't want to put forth the effort at the time, but I think that with the release of 1.4 it would be a good time to migrate from the Mochi Media hosted Trac and SVN over to something else. My personal preference is Google Code because we already use that for our other open source projects and it wouldn't require transitioning from a mainstream VC solution to something more obscure (e.g. launchpad, github). Per, do you have any thoughts on this? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Well, the login database is outside of trac since we're using basic auth to login and they are the same credentials that give svn commit access. Disabling anonymous commenting is something that I did because I couldn't be bothered to implement a better spam filter or maintain it. I'm not really sold on launchpad, I think bzr would be too much of a barrier to entry for many people. I would certainly consider moving to google code though, because that would be easy enough. All of our other open source projects are there these days. People that want to use distributed vcs to keep a local branch can do so easily enough with a central svn repo. On Mon, Oct 13, 2008 at 6:47 AM, Amit Mendapara <[EMAIL PROTECTED]> wrote: > > The version of trac is okay. See > http://trac.edgewall.org/wiki/TracPermissions, > you can easily prevent those spams. You can see how TurboGears trac is > configured... > > You can also think about moving MochiKit to Launchpad.net. It's really > a good platform to host OpenSource projects with distributed vcs, bug > tracking, blueprints and more. Launchpad team has already created a > project for MochiKit (so that no one then MochiKit team can claim the > ownership, you can contact Launchpad team to get ownership rights). > > - Amit Mendapara > > On Oct 13, 6:24 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote: >> On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara >> >> <[EMAIL PROTECTED]> wrote: >> > Once, I filed a bug report on the trac (related to Sortables), but I >> > was unable to change/comment it later. That's why I never submitted >> > again. >> >> Yes, this is very unfortunate. I used to have the same problem, so I >> hear you loud and clear. >> >> The problem is the amount of spam that we'd otherwise receive in bug >> reports. Don't know if there is some newer version of Trac that fixes >> this that we could install on the server. Or if there is some other >> solution that would work. Until that happens, emailing to this list or >> directly to the bug owner should work. Sorry about that. >> >> Cheers, >> >> /Per > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
If you'd like to fix it then I don't see why the patch would be rejected.
On Fri, Oct 10, 2008 at 7:57 PM, Jason Bunting
<[EMAIL PROTECTED]> wrote:
>
>
> That's it huh?
>
> No more discussion on this? I guess I am smoking crack...
>
> Jason
>
>
>> -Original Message-
>> From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On
>> Behalf Of Jason Bunting
>> Sent: Thursday, October 09, 2008 10:50 AM
>> To: 'Per Cederberg'; 'MochiKit'
>> Subject: [mochikit] Re: Why doesn't removeElement use the DOM Coercion
>> rules?
>>
>>
>>
>> > Per Cederberg wrote:
>> >
>> >
>> > Well... I think your case here is pretty uncommon. This is because the
>> > __dom__() function is really supposed to create a *new* DOM node.
>> > Otherwise people might run into issues when adding an object twice
>> > into the DOM tree.
>>
>> Excuse my ignorance, and permit me to ask a few questions so I can explore
>> this further...
>>
>> Line item 6 in the "DOM Coercion Rules," as posted in the documentation,
>> states:
>>
>>6. Objects that have a .dom(node) or .__dom__(node)
>> method are called with the parent node and their
>> result is coerced using these rules.
>>
>> So, perhaps there is some confusion because of the documentation, but I
>> don't see how my example code violates anything.
>>
>> I am confused by your statement that "Otherwise people might run into
>> issues
>> when adding an object twice into the DOM tree" - using my example, if
>> someone were to try to add myWidgetInstance to the DOM twice, the behavior
>> would be exactly as I would expect it - it is the same instances, and thus
>> it would only appear once (because the call to __dom__ would return the
>> same
>> instance). If the developer doesn't understand that this would happen,
>> then
>> they have other problems. Unless they instantiate another instance, there
>> should only be one.
>>
>> > But sure, there is an inconsistency here. My suggestion would be to
>> > just work around it instead:
>> >
>> > removeElement(myWidgetInstance.widgetDomRepresentation);
>>
>> IMO, that's terrible. It breaks encapsulation because now something that
>> should be private is made explicitly public. I don't want a workaround, I
>> want consistency in MochiKit's API.
>>
>> > Actually, other widget libraries tend to use the magic "dom" property
>> > for storing the root DOM node in the widget. Personally, I'd recommend
>> > using a mixin approach to widgets, just as I've done in the suggested
>> > MochiKit.Widget library:
>> >
>> > http://github.com/cederberg/mochikit-
>> > patches/tree/master/MochiKit/Widget.js
>>
>> I appreciate your comments, and while an API for widget building may
>> provide
>> some useful help, it isn't what I am looking for at the moment. The way I
>> have built widgets up to now (successfully, and for quite a while) is
>> pretty
>> much the way my example implies. It works beautifully and is simple enough
>> to be understood without an entire widget framework (notwithstanding the
>> fact that some help from using one might eventually be better than my
>> approach). I would simply like some consistency in the API - the following
>> functions all use the DOM Coercion Rules:
>>
>>appendChildNodes
>>insertSiblingNodesBefore
>>insertSiblingNodesAfter
>>createDOM
>>replaceChildNodes
>>...
>>
>> If those do, so should any of the others that expect DOM elements:
>>
>>removeElement
>>swapDOM
>>...
>>
>> If this is merely work that needs to be done, I would be willing to do it.
>> I
>> simply want to see if and why others don't see the inconsistencies that I
>> do.
>>
>> Thanks again,
>> Jason Bunting
>>
>>
>> > On Thu, Oct 9, 2008 at 1:01 AM, Jason Bunting
>> > <[EMAIL PROTECTED]> wrote:
>> > >
>> > > I don't know if I am "up in the night" on this or if it is an
>> oversight,
>> > but
>> > > why doesn't removeElement use the DOM Coercion rules in the same way
>> > that
>> > > something like appendChildNodes does? Here's some sample code that
>> > > illustrates my problem:
>> > >
>> > > function MyWidget() {
>> > >
>> > > var widgetDomRepresentation = DIV({style:"border:solid 1px"},
>> > "Hi!");
>> > > var that = this;
>> > >
>> > > connect(widgetDomRepresentation, "onclick", function() {
>> > > signal(that, "removeme");
>> > > });
>> > >
>> > > this.__dom__ = function() {
>> > > return widgetDomRepresentation;
>> > > };
>> > > }
>> > >
>> > > var myWidgetInstance = new MyWidget();
>> > > connect(myWidgetInstance, "removeme", function() {
>> > > removeElement(myWidgetInstance); // this
>> blows
>> > up
>> > > });
>> > > appendChildNodes(currentDocument().body, myWidgetInstance);
>> > >
>> > > It seems to make little sense that one can append myWidgetInstance to
>> > the
>> > > DOM using MochiKit.DOM functions, but can't remove it just as easily.
>> > >
>> > > Am I missing something here?
>> > >
>> > > Jason Bunting
>> > >
[mochikit] Re: Preparing for a MochiKit 1.4 release
Let's do it :) I'm out of town (in NYC instead of SF) this week but that means I have a few more cycles than usual to spend on open source. -bob On Wed, Oct 8, 2008 at 9:54 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > This is a long email in the series "why don't we release 1.4 > already?". But at least I tried to shorten down the opinion pieces. > > #1. Importance of a release > > Personally I think it is important that we do a release of version > 1.4. Other projects (e.g. TurboGears) tend to depend on stable > releases. And it is good advertising for the project to have regular > releases. > > I know lots of people here use the svn version and are happy with > that. But I find the value of a proper MochiKit 1.4 release > sufficiently large to volunteer as a maintainer for the stable > version. > > #2. Now rather than later > > I also think we are long overdue with a 1.4 release. As the stars are > currently aligned in an optimal constellation, I think now is the > perfect time for a release. Just today we've finally fixed the last > reported bug in MochiKit 1.4 (but for some issues I'll close as > worksforme/wontfix unless I get feedback). > > You can find the current bug list here -- http://trac.mochikit.com/report/3 > > #3. Feature freeze > > I know several people want to push bits into MochiKit at the moment > (myself included). But new features invariably mean new bugs. And we > currently have a stable bug-fixed version that has not undergone much > change for about a year. > > I'd like us to push that version out the door with the 1.4 label > attached before doing surgery in MochiKit.Selector, adding widgets, > new string formatting, or other stuff. Those of us that use svn trunk > will still be able to get all that stuff in a few weeks once the > release has been tagged and development on 1.5 begins. > > Personally I'd suggest a two week freeze before the release, but that > is a matter of taste. > > #4. Testing, testing, testing > > In order find any remaining issues in version 1.4, I'd like to > encourage everyone to test their apps/websites with the latest svn > trunk version of MochiKit. Issues can be reported either directly on > trac.mochikit.com or on this mailing list. I'll try to address each > and every one in a timely manner. > > You can also contribute by running the test suite in your favorite > browser environments. Below is a link and the results as of today. > > http://svn.mochikit.com/mochikit/trunk/tests/index.html > > Linux - Firefox 3 - OK > > Mac - Firefox 3 - OK > Mac - Safari 3 - OK > Mac - Opera 9.6 - OK > Mac - IE 6 (via CrossOver) - OK > > Windows - IE 7 - OK > Windows - Firefox 3/Windows - OK > Windows - Safari 3 - OK > Windows - Chrome Build 2200 - OK > > Opinions? What does Bob think? > > Cheers, > > /Per > > PS. I just discovered that Google Groups silently dropped all my > emails that used another sender address, so I'm currently resending > all my recent postings. Hence the sudden email bombing... > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.Async.doXHR
It looks like your problem is that your usage of partial probably
doesn't do what you intend it to.
request.addCallBacks(
partial(this.typeLoaded, i),
partial(this.typeFailed, i)
);
With that expression, you lose the binding to "this" (since JavaScript
has no bound methods).
You probably want to use bind or method instead of partial in such a
way that you can keep the "this" binding.
-bob
On Wed, Oct 1, 2008 at 10:41 PM, Akari no ryu <[EMAIL PROTECTED]> wrote:
>
> I've been battling with this for a few hours now, been reading the
> docs and read this groups mails on defferred.callback
> None of that seems to help.
> My code does the following:
>
>this.interfaceTypes = {
>'lines':false,
>'regions':false,
>'points':false
>};
>for(var i in this.interfaceTypes)
>{
>var url = i+'.php';
>var queryString =
> MochiKit.Base.queryString({'do':'fetchTypes'});
>log('created url of '+url+' and queryString of '+queryString);
>try
>{
>var request = MochiKit.Async.doXHR(url);
>request.addCallBacks(
>partial(this.typeLoaded, i),
>partial(this.typeFailed, i)
>);
>}
>catch(e)
>{
>for(var j in request)
>{
>log('request.'+j+"\n"+request.j)
>}
>}
>}
>
> For all values of request's properties, it's showing up as undefined.
>
> Also, if I don't litter my constructor with log calls, the log calls
> don't happen in there and a log call after it won't happen either.
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
On Fri, Sep 12, 2008 at 9:01 AM, csnyder <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 3:53 PM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
>> Suggested formatting types:
>> s - Output from toString(), this is the default
>> r - Output from MochiKit.Base.repr()
>> b - Binary. Outputs the number in base 2.
>> c - Character.
>> d - Decimal Integer. Outputs the number in base 10.
>> o - Octal format. Outputs the number in base 8.
>> x - Hex format. Outputs the number in base 16, using lower-case letters.
>> X - Hex format. Outputs the number in base 16, using upper-case letters.
>> f - Fixed point number.
>> % - Percent conversion for a fixed point number (and adds a '%' char
>> at the end).
>> ... perhaps some format for exponents (but it would be hard to implement)
>> ... and some nice time formatting stuff
>
> What about currency (amount) formatting?
>
> Or is that just "$"+format("{0:0.2d}", 1.6) ?
>
> It wasn't immediately clear to me from the examples how you get a
> precision 2 decimal number, which is likely to be one of the most
> requested formats.
d is for integers, f is for fixed point.
1> mochifmt:f("${0:.2f}", [1.234]).
"$1.23"
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
I think we should keep deep object names, JSON data structures are
often nested a little bit and it's nice to be able to work with them
as-is without creating a new object just to flatten it out.
As far as nested replacements go, I think we can ditch that safely.
I've never really wanted to use that.
Otherwise the proposal looks good! :)
On Wed, Sep 10, 2008 at 12:53 PM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
> Thank you everyone for the interesting comments. I had a look at PEP
> 3101 (Python 3), the (new) Java 1.5 Formatter API and a popular
> sprintf implementation for JavaScript. And in the end, it seems hard
> to strike a good balance between readable syntax, power features and
> localization. Actually, I think they all fail at one or the other.
>
> In PEP 3101 I couldn't find any mention of the thousand separator (at
> first, but now I just realized that ":n" should be used). The Java
> Formatter API took the already ugly sprintf-syntax to new heights of
> unreadability. And the standard sprintf variants are problematic for
> localized format strings where the order of the parameters might
> change.
>
> So, I'm thinking about using a simplified version of PEP 3101 with a
> few add-ons to enable most of what is possible with the current
> numberFormatter function.
>
> I'm thinking that the API should look something like:
>
> // Create a formatter function for specified pattern & locale
> MochiKit.Format.formatter(pattern/*, locale="default" */)
> ==>
>
> // Short-cut that immediately applies the formatter on the specified args
> MochiKit.Format.format(pattern/*, ... */)
> ==>
>
> Perhaps a few examples would best explain the formatting patterns:
>
> // Simple positional replacements
> format("A {1} string with {0} arguments.", "numeric", "format")
> ==> "A format string with numeric arguments."
>
> // Or we use object properties
> format("{name} == {value}", { value: 2, name: "a" })
> ==> "a == 2"
>
> // As usual, escaping is performed by double chars
> format("{{}}")
> ==> "{}"
>
> // Differing from Python, the default is a toString()
> format("{0}", 1/3)
> ==> "0."
>
> // Naturally, null is supported as "null"
> format("{0}", null)
> ==> "null"
>
> // We can force a decimal format
> format("{0:d}", 1.5)
> ==> "1"
>
> // And a fixed number of characters
> format("{0:4d}", -4)
> ==> " -4"
>
> // We can force the field to be left-aligned
> format("{0:<4d}", 4)
> ==> "4 "
>
> // Or add zero padding
> format("{0:04d}", 4)
> ==> "0004"
>
> // Using the repr() output
> format("{0:r}", "foo")
> ==> "\"foo\""
>
> // I suggest we skip nested replacements due to complexity
> format("{0:{1}}", 4, 3)
> ==> error, but in Python it would be " 4"
>
> // I'd also reject deep object names as it is just not useful enough
> format("{sub.name}", { sub: { name: "Alice" } })
> ==> error, but in Python it would be "Alice"
>
> So the format for the replacement string is:
> "{" key ":" fmt "}"
>
> The format string has the following (Python) format:
> [flags][width][.precision][type]
>
> Flags:
> '>' - Forces the field to be right-aligned (default).
> '<' - Forces the field to be left-aligned.
> '+' - Sign should be used for both positive and negative numbers.
> '-' - Sign should be used only for negative numbers (default).
> ' ' - Leading space should be used on positive numbers.
> '0' - Numbers will be zero-padded to the specified width.
> ',' - The result will include locale-specific grouping (thousand separators).
>
> Width specifies the minimum field width. The precision indicates how
> many digits should be displayed after the decimal point in a floating
> point conversion. For non-numeric types the field indicates the
> maximum field size.
>
> Suggested formatting types:
> s - Output from toString(), this is the default
> r - Output from MochiKit.Base.repr()
> b - Binary. Outputs the number in base 2.
> c - Character.
> d - Decimal Integer. Outputs the number in base 10.
> o - Octal format. Outputs the number in base 8.
> x - Hex format. Outputs the number in base 16, using lower-case letters.
> X - Hex format. Outputs the number in base 16, using upper-case letters.
> f - Fixed point number.
> % - Percent conversion for a fixed point number (and adds a '%' char
> at the end).
> ... perhaps some format for exponents (but it would be hard to implement)
> ... and some nice time formatting stuff
>
> I think the above would support most of the common use cases for
> formatting, while leaving it fairly simple to implement in plain
> JavaScript. If more advanced formatting is required, one can always
> write specialized functions that re-use these components accordingly.
>
> Opinions? Think I'll start on this next week otherwise.
>
> Cheers,
>
> /Per
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this grou
[mochikit] Re: Formatting strings, numbers and stuff
On Wed, Sep 10, 2008 at 5:55 AM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
> I guess this is a question for Bob, but others might have some clues
> here also. Thus sending it to the list.
>
> I've recently done some Python coding and found the % string formating
> there very convenient. Now, as MochiKit is so inspired by Python, I
> find it a bit odd that there is no generic string formatting similar
> to the Python version. Is this just due to lack of time or is it a
> deliberate omission?
>
> The MochiKit.Format.numberFormatter function is of course very
> powerful, but it doesn't provide everything that the Python equivalent
> does:
>
> 1. No type selection mechanism. Cannot format strings, random objects
> or hexadecimal, octal, binary or floating point exponential numbers.
> 2. No generic string formatting. Cannot output "Value: %d" or similar.
> 3. Inconvenient API for throw-away formatting. You have to create a
> formatting function and then call it (very Java-ish).
>
> Has anybody created a generic formatting function in JavaScript? Other
> libraries? Or am I the only one seeing the need?
I've wanted to have it once or twice, but the number formatting has
worked out well for what I wanted to do. Conversely, Python's
formatting functions don't allow you to put thousands separators in
numbers, which is something we do very often.
The number formatter uses the same spec as Java does so the way it
acts should be of little surprise. The API isn't terribly inconvenient
other than the length of the name I guess, since functions are first
class. numberFormatter("###,###%")(2134) isn't that much longer than
say formatNumber("###,###%", 2134) or something like that.
If we do implement a string formatting library my personal preference
would be the advanced string formatting from PEP 3101 that is going
into Python 2.6/3.0:
http://www.python.org/dev/peps/pep-3101/
We've also got a similar Erlang implementation here:
http://code.google.com/p/mochiweb/source/browse/trunk/src/mochifmt.erl
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Thu, Aug 28, 2008 at 3:04 AM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 28, 2008 at 05:35, Amit Mendapara <[EMAIL PROTECTED]> wrote: >> Another problem to which I am not sure is licensing issue, Sizzle is >> MIT licensed while MochiKit has dual MIT/AFL license. I myself >> thinking of releasing my code under any FSF approved licenses like MIT >> or GLP. Do you see any difficulties of including these sources to >> MochiKit particularly under AFL? > > To be honest, I don't know. > > Bob, or anyone, do you know if there are problems with this? > > If there are, John Resig was keen on the idea so he might make some > arrangements for us. I don't think there should be a problem with that, since AFL doesn't give any permissions that don't already exist in MIT, but IANAL. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Random Ideas for Mochikit.DOM
On Tue, Aug 26, 2008 at 6:34 PM, machineghost <[EMAIL PROTECTED]> wrote: > > First off, I do <3 Mochikit. I wasn't trying to bash it, I just > wanted to share my opinion of it with someone who seemed to be in a > similar position. > >>> part of the reason changes are looked at with suspicion is because >>> a lot of suggestions are not in keeping with the intent of MochiKit. > Suspicion is one way to describe it; I'd lean more towards "outright > hostility" (although said hostility is generally civil and polite, > which is more than I can say for a lot of lists). And as for the > intent of MochiKit, I thought it was to "make JavaScript suck less." > It does that to some degree right now, but do you really think it's > impossible for JS to suck even less? I don't (JS sucks a lot, and I > say that even though it's one of my favorite languages). Yes, it's certainly possible, but it does what we want it to do... if it didn't, you'd see a lot more commits from us. >>> Is the lack of development necessarily indicative of a problem? > Absolutely, the health of any open source project is measured by it's > activity. As a JS implementer I need to know that the (JS framework) > horse I bet on is going to respond to my future needs in a timely > fashion. I have great confidence of that with JQuery because it has > an extremely active development community; try comparing the activity > on their list: >http://groups.google.com/group/jquery-en?lnk=srg > to the activity here and you can see why I don't have similar > confidence in Mochikit. Alternatively you can compare the membership > of the groups, the # of Google results for searches on "MochiKit" vs. > "JQuery", the # of commits to either library in the last year, ... > whatever metric you use, Mochikit always comes in last compared to not > just JQuery, but every other major JS library (prototype, YUI, dojo, > etc.) as well. If you want something popular with a vocal community and lots of new developments, you're in the wrong place and that's been the situation for a long time. I don't think anyone here would try and convince you otherwise. >>> what things is it missing? > Well there are two just in this thread alone: chainability and > additional element methods. Another great example from JQuery is the > onDOMReadyState pseudo-event. But again, it's not just the feature by > feature comparison between frameworks that matters; five years ago I > could not have predicted the need for an XmlHttpRequest abstraction, > but that's obviously a very essential feature for a JS library today. Chainability probably is not going to happen, but onDOMReadyState certainly should at some point. If you really like chainability, you should probably be using jQuery. That's what it's good at, but I personally don't care much for that style. jQuery is a perfectly good library for what it intends to do, if it does w hat you want it to how you want it to be done, why not just use it? MochiKit is here because it solves a lot of problems that we had a couple years ago before jQuery existed. Were it around in 2005 I might've just used it instead of writing my own, but dojo and prototype were not really worth using at the time. I have no real vested interest for you to use MochiKit. I'm not involved with any kind of consulting, I don't intend to write any books, not particularly interested in speaking at any more conferences about JS, etc. It helps me and my company out when people contribute code, file bugs, etc. because this is the library we use. In other words, I don't really care if you use MochiKit or not. > If my company had adopted some framework based solely on it's feature- > set back then, and that framework had never added an XmlHttpRequest > abstraction, I'd be up a proverbial creek without a paddle. I'd have > to convert all of our code to use a new library or else use two > libraries (and have a giant download footprint); either way I'd be > kicking myself for not choosing an actively developed framework. > >>>I don't see the library itself as missing anything. > There are still hundreds of opportunities to make JS suck less, but > Mochikit is missing all of them while libraries like JQuery either > respond to them directly (by adding new stuff to the library) or > indirectly (via something like JQuery's plug-in mechanism). All JavaScript frameworks have "plug-in mechanisms"... you can add whatever code you want to the runtime system. From what I recall, jQuery's plug-in mechanism is just there to make it easy to inject things into jQuery's namespace such that it's chainable, which is not something MochiKit needs. MochiKit is more of a collection of libraries than a framework in that sense, because you don't need a plug-in mechanism, you just add more code. >>>Is this because they wouldn't add a few aliases for you? > Hardly. I personally have proposed not just that but several other > enhancements, and of course I'm not the only one who has made > su
[mochikit] MochiMedia looking for Web Developers
If you're reading this list, we know you use MochiKit, so how about coming and working with the team that developed it in the first place? We're looking for a Senior Web Application Developer experienced using Python, Pylons, MochiKit, SQLAlchemy, etc. Here's a short job description. Reply back to [EMAIL PROTECTED] if you're interested! Senior Web Application Developer for Mochi Media We're looking for a Sr Web Developer to build out applications in Python to support our network of Flash game developers. The ideal candidate has 5+ years of experience building applications for large web brands, loves to iterate designs, gets agile development, and is unafraid of diving into any area the problem leads him/her to. You should have opinions on programming languages, frameworks and styles, yet be versatile enough to use any of them. CSS/DHTML/AJAX pour out of your mind and into code as fast as you can type it. If I've described you, let me now describe us. Mochi Media is a fast growing startup based in San Francisco. We build a platform for Flash game developers with in game advertising as a key focus for the developers. We just closed our series B round, and we're looking to ramp the company quickly. We're a small team with a very high bar for the types of people we'll bring in led by me (CTO and co-founder) and Eric Boyd our VP Eng. Mochi Media key stats 20% impression growth every month for almost a year. 60MM unique users every month. Strong and rapidly growing revenues. Small team where you can come in and have an immediate impact -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Problems using partial toggleElementClass as an event handler...
On Sun, Jul 6, 2008 at 9:46 PM, Jason Bunting
<[EMAIL PROTECTED]> wrote:
>
>
> I have this code in a control I have built:
>
> var ldel = this.LaborDataEntryList;
> connect(this.ExpandCollapseButton, "onclick", function() {
> toggleElementClass("Invisible", ldel);
> });
>
> What I originally tried to do was this:
>
> connect(this.ExpandCollapseButton, "onclick", partial(toggleElementClass,
> "Invisible", this.LaborDataEntryList));
>
> Problem is, when the event fires the result of the partial also gets the
> additional event argument sent to it and it blows up within addElementClass
> (which is called by toggleElementClass); is there anything that can be
> reasonably done to prevent this from happening or do I need to accept that I
> will have to write this code with the lambda?
You'll have to use the anonymous function, but if you find yourself
doing it a lot you can always write your own higher order function
that returns an appropriate anonymous function.
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Flash/Flex port of Deferred?
I've done it before, for AS2 a long time ago (it was the predecessor of the JS implementation). Porting should just be cut + paste, MochiKit's Deferred doesn't do anything outside of the ECMAScript profile that Flash supports. On Mon, Jun 23, 2008 at 7:12 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote: > > Hi all, > > Does anybody know if there is an ActionScript port of MochiKit.Deferred? > > I'd love the API and I'd like to use it on Flex (basically for > RemoteObject interaction). I'm willing to port the code, but hopefully > someone did it before. > > OTOH, If nobody has done it yet, maybe there is a good reason which I > may have missed... > > Thanks, > -- > Leo Soto M. > http://blog.leosoto.com > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Django doXHR Headers and Guidance
mimeType: 'application/javascript' doesn't do what you think it does,
it's the overrideMimeType on the XHR. For JSON it doesn't matter since
it only uses responseText, I think it's only useful for setting it to
XML.
I think your problem is that XMLHttpRequest has a responseText
attribute, not response_text.
However you should probably just use MochiKit's evalJSONRequest
instead of doing the eval yourself.
-bob
On Mon, May 12, 2008 at 9:07 AM, Szaijan <[EMAIL PROTECTED]> wrote:
>
> Hi Folks,
>
> I have a Django application with a scratch-built AJAX Javascript layer
> that works well on Safari and Firefox, but not on IE. I am attempting
> to rewrite it using MochiKit, but am having some issues with the doXHR
> function, in that I seem to be getting back an empty XHR from my
> Django Python script. I have a few questions:
>
> 1) Can anyone see what I'm doing wrong in the MochKit code? As I
> said, I get back an empty XHR. Am I accessing the return XHR
> incorrectly (should be the "result" argument in my callback, right?)
> When I use typeof(result) I get the expected XHR type.
> result.toJSONString() yields {}.
>
> 2) In the first code sample, I am able to access
> ajaxRequest.response_text, which should be the same as
> resulot.response_text in the MochiKit example, but the result appears
> to be empty. Do I need to do something different to access the fields
> of the doXHR result argument?
>
> 3) Am I getting back an empty result because doXHR sets some default
> headers for the request that are incompatible with the Django return
> type? What would be a good set of headers to use?
>
> The generic code that works looks like:
>
> selectEntity : function (entity)
> {
> try
> {
> var url = '/visionary/game/select/?xhr';
> var eId = 'harp_game_id';
> var getData = eId + '=' + escape(entity.pk);
> var ajaxRequest = this.createRequest(); // Creates a
> generic, platform appropriate XHR
> ajaxRequest.open("POST", url, true);
> ajaxRequest.onreadystatechange =
> MochiKit.Base.bind(function ()
> {
> try
> {
> if(ajaxRequest.readyState == 4)
> {
> if(ajaxRequest.status == 200)
> {
> var response = eval( "(" +
> ajaxRequest.responseText + ")");
> if (response.success)
> {
> var consoleMessage =
> response.initial_console_message;
>
> MochiKit.Base.map(MochiKit.Base.bind(function (index) {
> consoleMessage += " " +
> index + ": " + response[index];
> var rowId = [this.app,
> this.cn, response[index], 'row'].join('_');
>
> this.setRowHighlight(MochiKit.DOM.getElement(rowId),
> index ==
> 'newId' ? true : false);
> }, this), ['newId', 'oldId']);
>
> this.updateConsole(consoleMessage);
> }
> else
> {
> this.errorsToConsole(response);
> }
> return true;
> }
> }
> }
> catch(e)
> {
> MochiKit.Logging.logError('selectEntity
> Callback fn ' + e);
> }
> return false;
> }, this);
> ajaxRequest.setRequestHeader("Content-Type", "application/
> x-www-form-urlencoded");
> ajaxRequest.send(getData);
> return true;
> }
> catch(e)
> {
> MochiKit.Logging.logError('selectEntity(' + entity + ') '
> + e);
> }
> return false;
> }
>
> The MochiKit heavy code I can't get a response from looks like:
>
> selectEntity : function (entity)
> {
> try
> {
> var url = '/visionary/game/select/?xhr';
> var q = 'harp_game_id=' + entity.pk;
> var r = {method: 'POST',
> mimeType: 'application/javascript',
> headers: [['Content-Type', 'application/x-www-
> form-urlencoded'],
> ['Accept', 'application/
> json']],
> sendContent: q};
> var d = MochiKit.Async.doXHR(url, r);
> d.addCallback(MochiKit.Base.bind(function (result) {
> try
> {
> MochiKit.Logging.log('Callback Request: ' +
> result);
> var response =
[mochikit] Re: Updated docs for MochiKit.Visual
This looks good to me, thanks! On Mon, Mar 24, 2008 at 9:45 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > I've finished updating the docs for MochiKit.Visual now. The clarified > version is available on the usual place: > > http://mochikit.com/doc/html/MochiKit/Visual.html > > Please let me know if you find any issues or typos in this version. > > /Per > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 1.4 release
On Fri, Apr 18, 2008 at 8:01 AM, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > > Bob Ippolito schrieb: > > Documentation patches are key, and having more examples for the > > features in Visual would at least prove that they work under *some* > > circumstance :) > > I just noticed that MochiKit already has an example page for the visual > effects, in the examples/effects folder. I think it would be good to > have this on the demos page http://www.mochikit.com/demos.html Thanks for the suggestion, just committed that :) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Reasons to not use a simple ondomload signal?
Yeah, the major problem of doing a synthetic ondomload event like that
is that you need to instrument all of your pages with that script tag
at the bottom. It's "nicer" to do it via DOM calls because you don't
need to change the markup.
-bob
On Thu, May 8, 2008 at 12:16 PM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
> Antti Koivisto, one of the Safari browser developers, wrote an
> interesting blog entry about page loading recently. It explains some
> of the difficulties involved from a browser perspective:
>
> http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/
>
> And a small extract of the most relevant section:
>
> ---
> Problems start when a document contains references to external
> scripts. Any script can call document.write(). Parsing can't proceed
> before the script is fully loaded and executed and any
> document.write() output has been inserted into the document text.
> Since parsing is not proceeding while the script is being loaded no
> further requests for other resources are made either. This quickly
> leads to a situation where the script is the only resource loading and
> connection parallelism does not get exploited at all. A series of
> script tags essentially loads serially, hugely amplifying the effect
> of latency.
> ---
>
> So, in my understanding, putting a tag at the very end of the
> HTML text on the page should be nearly identical to actually waiting
> for the onDOMLoad event. All the document text should have been parsed
> already and be available in the DOM tree.
>
> One of the many issues with "onload" is also the latency involved in
> loading images and CSS files, which actually adds up to quite some
> time (as most browsers only request 2 objects simultanously per web
> site).
>
> /Per
>
> On Thu, May 8, 2008 at 7:10 PM, machineghost <[EMAIL PROTECTED]> wrote:
>>
>> As I understand things (and I am by no means a JS event sequence
>> expert), the ordering is as follows:
>>
>> 1. Browser reads page line by line; every time it reads enough lines
>> to complete a JS statement, it executes that statement; meanwhile, non-
>> JS content is loaded in to the DOM as it is read
>> 2. Once the browser has finished reading the page it will have a
>> complete DOM ... in memory.
>> 3. The browser will then render that DOM tree to your screen.
>> 4. Once it has finished rendering the DOM tree, it invokes any
>> "onload" events.
>>
>> Technically that's wrong, because the first three things are really
>> happening simultaneously (ie. the browser starts rendering the top of
>> the page even before it has a complete DOM loaded), but it's simpler
>> to think of it that way (because they will almost always finish in
>> that order).
>>
>> The "problem" with your code, as I understand it, is that your code
>> goes off in #1, which means there is no guarantee that a complete DOM
>> will exist. If you instead wait for "onLoad" though, you have to wait
>> for the page to render. So what people who are interested in the
>> "onDOMLoad" event are after is getting an event that triggers after 2
>> but before 3. That way, you don't have to wait for the page to
>> render, and as long as your code doesn't require any rendered
>> information (like "what are the dimensions of $('someElement')") it
>> should work fine.
>>
>> But all of the above was written with my very flawed understanding of
>> the JS event model; please take it with a giant helping of salt.
>>
>> Jeremy
>>
>> On May 8, 9:37 am, csnyder <[EMAIL PROTECTED]> wrote:
>>> Hi MochiKitters,
>>>
>>> I've been using the following trick successfully for a few months now.
>>> It _seems_ to work fine cross-browser and cross platform.
>>>
>>>