Re: [mochikit] Does anyone use this?

2017-05-26 Thread Bob Ippolito
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?

2017-05-25 Thread Bob Ippolito
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

2011-10-16 Thread Bob Ippolito
On Sun, Oct 16, 2011 at 6:09 AM, Jurgens de Bruin debrui...@gmail.com 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] Is MochiKit Dead?

2011-08-15 Thread Bob Ippolito
Good idea. Done!

On Mon, Aug 15, 2011 at 4:20 AM, Chris Snyder chsny...@gmail.com 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?

2011-08-13 Thread Bob Ippolito
On Sat, Aug 13, 2011 at 11:35 AM, machineghost machinegh...@gmail.com 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

2011-01-11 Thread Bob Ippolito
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 cederb...@gmail.com 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.                 |
    +-+-+



 API Reference
 =

 Functions
 -

 

Re: [mochikit] Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)

2010-12-04 Thread Bob Ippolito
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 p...@percederberg.net 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 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 :( ):
 http://bitbucket.org/rwilcox/learning_javascript/src/tip/MochiKit/
 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?

2010-11-20 Thread Bob Ippolito
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 fblomqv...@gmail.com 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 fblomqv...@gmail.com 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

2010-10-12 Thread Bob Ippolito
It was for Aptana, not sure if anyone still cares?

On Tuesday, October 12, 2010, Per Cederberg cederb...@gmail.com 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

2010-10-10 Thread Bob Ippolito
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] svn.mochikit.com and trac.mochikit.com down

2010-10-07 Thread Bob Ippolito
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 ethan.juc...@gmail.com 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] SpiderMonkey and MockDOM Issues

2010-10-07 Thread Bob Ippolito
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 theka...@gmail.com 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] Re: SpiderMonkey and MockDOM Issues

2010-10-07 Thread Bob Ippolito
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 theka...@gmail.com 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 b...@redivi.com 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 theka...@gmail.com 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] Mochikit.js does not download from Apache 2.2.3 on Centos 5.4/5.5

2010-06-09 Thread Bob Ippolito
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 jonau...@nescent.org 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

2010-04-27 Thread Bob Ippolito
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 saik...@gmail.com 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

2010-02-18 Thread Bob Ippolito
You can send it here to the list

On Thu, Feb 18, 2010 at 3:18 AM, niek.kouwenb...@gmail.com
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

2010-01-02 Thread Bob Ippolito
On Sat, Nov 28, 2009 at 2:18 PM, Per Cederberg cederb...@gmail.com 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

2009-11-04 Thread Bob Ippolito

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 cederb...@gmail.com 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 bea...@gmail.com 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

2009-07-16 Thread Bob Ippolito

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, Michaelmstras...@gmail.com 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

2009-05-20 Thread Bob Ippolito

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 rupert.ba...@gmail.com 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 b...@redivi.com 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 rupert.ba...@gmail.com 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

2009-05-19 Thread Bob Ippolito

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 rupert.ba...@gmail.com 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: doSimpleXMLHttpRequest, IE and non ascii characters

2009-04-16 Thread Bob Ippolito

You probably need to use encodeURIComponent.

2009/4/16 Boštjan Jerko ml...@japina.eu:

 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 #96; 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?

2009-03-29 Thread Bob Ippolito

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 cederb...@gmail.com 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 zin...@gmail.com 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

2009-02-10 Thread Bob Ippolito

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 cederb...@gmail.com 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
 mendapara.a...@gmail.com 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

2008-12-18 Thread Bob Ippolito

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 cederb...@gmail.com 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 arna...@gmail.com 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

2008-12-12 Thread Bob Ippolito

On Fri, Dec 12, 2008 at 11:20 AM, Arnar Birgisson arna...@gmail.com wrote:

 Hi

 On 12.12.2008, at 16:45, Eoghan eoghanomur...@gmail.com 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?

2008-11-26 Thread Bob Ippolito
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: MochiKit 1.4.1 released

2008-11-02 Thread Bob Ippolito

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: MochiKit 1.4 released

2008-10-21 Thread Bob Ippolito

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: Selector speedup by using John Resig's Sizzle

2008-10-13 Thread Bob Ippolito

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] Migrate to Google Code?

2008-10-13 Thread Bob Ippolito

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?

2008-10-13 Thread Bob Ippolito

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] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?

2008-10-13 Thread Bob Ippolito

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: Migrate to Google Code?

2008-10-13 Thread Bob Ippolito

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: Why doesn't removeElement use the DOM Coercion rules?

2008-10-10 Thread Bob Ippolito

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
  
  
   
  
 
  
 
  No virus found in this incoming message.
  Checked by AVG - http://www.avg.com
  Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date:
 10/9/2008
  9:44 AM


 

 No virus found in this incoming message.
 Checked by AVG - http://www.avg.com
 Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008
 9:44 AM


 



[mochikit] Re: MochiKit.Async.doXHR

2008-10-02 Thread Bob Ippolito

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

2008-09-12 Thread Bob Ippolito

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

2008-09-10 Thread Bob Ippolito

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: Formatting strings, numbers and stuff

2008-09-10 Thread Bob Ippolito

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 */)
 == function object

 // Short-cut that immediately applies the formatter on the specified args
 MochiKit.Format.format(pattern/*, ... */)
 == formatted string

 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 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

2008-08-28 Thread Bob Ippolito

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

2008-08-27 Thread Bob Ippolito

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
 suggestions, yet almost no improvements have come out of any of that
 

[mochikit] MochiMedia looking for Web Developers

2008-07-15 Thread Bob Ippolito

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...

2008-07-07 Thread Bob Ippolito

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?

2008-06-23 Thread Bob Ippolito

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

2008-05-12 Thread Bob Ippolito

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 += br+
  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 = eval( ( +
  result.response_text + ));
 if(typeof(response) != 'undefined')
 {
 

[mochikit] Re: 1.4 release

2008-05-10 Thread Bob Ippolito

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: Updated docs for MochiKit.Visual

2008-05-10 Thread Bob Ippolito

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: Reasons to not use a simple ondomload signal?

2008-05-08 Thread Bob Ippolito

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 script 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.

 script type=text/javascript
   signal(window,'ondomload');
 /script
 /body
 /html

 But based on the recent thread about implementing ondomload, I assume
 that there must be cases when a simple signal at the end of the dom
 isn't enough.

 Can anyone give me a quick earful about why the above isn't the best
 way to do it?

 --
 Chris Snyderhttp://chxo.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: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread Bob Ippolito

This would definitely be convenient, it's always been on my list and
I've hacked together crappy (polling) implementations once or twice,
but I never needed it bad enough to tackle all of the cross-browser
issues myself :)

On Tue, May 6, 2008 at 10:51 PM, Per Cederberg [EMAIL PROTECTED] wrote:

  I liked the ondomready name and structure. Looking at MSDN, they
  provide the following solution instead of writing new script tags into
  the document (not tested, just pasted):

  document.onreadystatechange=fnStartInit;
  function fnStartInit()
  {
if (document.readyState==complete)
{
   // Finish initialization.
}
  }

  Otherwise I like the proposed solutions and vote for inclusion to
  MochiKit.Signal. Never know when it might be handy.

  Cheers,

  /Per



  On Wed, May 7, 2008 at 6:21 AM, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
  
oops, some mistake in the webkit part, sorry
  
[code]
  
   if (/WebKit/i.test(navigator.userAgent)) {
 var __domready__timer__ = setInterval(function() {
   if (/loaded|complete/.test(document.readyState)) signal(window,
'ondomready');
   clearInterval(__domready__timer__);
 }, 10);
[/code]
  
  
  
On 7 mayo, 00:12, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
 MochiKit is wonderful, as you wrote ir, but is the base, you can made
 too much things, but you may need read or investigate some more time
 like jQuery.

 I prefer call it domready, because it is when dom nodes are loaded, i
 use this code to implement domready, and i not have any problem.

 [code]
 var __domready__ = false;
 if (document.addEventListener)
 document.addEventListener(DOMContentLoaded, function() { if(!
 __domready__) { __domready__ = true; window.signal(window,
 'ondomready') }; }, false);

 /[EMAIL PROTECTED] @*/
 /[EMAIL PROTECTED] (@_win32)
 document.write(script id=__ie_onload defer
 src=javascript:void(0)\/script);
 document.getElementById(__ie_onload).onreadystatechange =
 function() {
 if (this.readyState == complete) {
 signal(window, 'ondomready');
 }
 };
 /[EMAIL PROTECTED] @*/

 if (/WebKit/i.test(navigator.userAgent)) {
   var __domready__timer__ = setInterval(function() {
 if (/loaded|complete/.test(document.readyState)) signal(window,
 'ondomready');
 clearInterval(ctimer);
   }, 10);}

 [/code]

 and when i need to call them i use

 [code]
 connect(window, 'ondomready', function () {
   alert('now i know kung fu');});

 [/code]

 Felipe Alcacibar Buccioni
 Developer of systems and solutions

 On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote:

  Hey All,

  In trying to explain why he liked jQuery, a co-worker of mine clued me
  in to a fairly cool method in that library: ready(someFunc);.  For
  those who aren't familiar with jQuery, you can think of this method as
  something like:
  partial(connect, document, DOMContentLoaded)

  In other word, it connects the provided function to the
  DOMContentLoaded document event.  Now, the specific jQuery syntax I
  could care less about (with partial I can already make any connect
  variant I want), but what is really cool about the function is that it
  makes it really easy to use the DOMContentLoaded event.  And why is
  that cool?

  1) The DOMContentLoaded event fires sooner (and if you have a heavy
  page, MUCH sooner) than the onLoad event (although you can't do
  stuff that depends on the rendered DOM, like getElementDimensions,
  until onLoad goes off).  As a result, you can get significant
  performance improvements just by changing (most of) your onLoad code
  to be onDOMContentLoaded code.

  2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
  however, this guy:http://javascript.nwbox.com/IEContentLoaded/
  figured out a hack to emulate the event in IE.  When you call
  ready(someFunc), behind the scenes JQuery handles figuring out
  whether to use the hack or the real event.

  Now, I don't have any desire to switch to jQuery; it has the same
  basic stuff as Mochikit, but none of the wonderful advanced stuff like
  partial, keys, etc.  I would however like to have access to this
  fake event.  Am I alone in this, or would others on this list like
  to see a synthesized Mochikit DOMContentLoaded event (similar to the
  existing synthesized onmouseenter and onmouseleave events)?

  If there is interest in this event I'll be happy to help write a
  proper Mochikit patch, but if not I'll just steal (quick and dirty
  style) the jQuery event for my own purposes.

  

  


--~--~-~--~~~---~--~~
You received this message 

[mochikit] Re: Problem with packed version in trunk

2008-03-23 Thread Bob Ippolito

On Sun, Mar 23, 2008 at 12:10 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:

  I just stumbled upon an error when using MochiKit with HTML, and it took
  me some time to realize that it already has been fixed, but not in the
  packed vresion I was using - the packed version of MochiKit in the trunk
  does not contain the bugfix in r1335. You should either use a pre-commit
  hook to make sure that the packaged version is always in sync, or not
  keep the packed version the repository at all.


Neither of those options are very practical, but thanks for letting us
know that it got out of sync. It usually isn't.

-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: Can MochiKit support Comet/http push/long polling ???

2008-03-04 Thread Bob Ippolito

I've implemented long-polling with MochiKit before. The JavaScript
doesn't really change all that much, you just use doXHR like you
normally would, the response just doesn't come back for a while and as
soon as you get one then you make another one, and you have to have
some sort of empty response that you ignore.

It doesn't make a whole lot of sense to implement more than one or two
of the comet mechanisms.. Long polling works pretty well across the
board, for example.

On Mon, Mar 3, 2008 at 9:43 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

  I'm a big fan of MochiKit and it has served me well.

  I recently learned I can replace AJAX polling with something much
  better
  called Comet aka long polling aka http push.

  I know there is a TurboGears+Dojo presentation at Pycon on this but I
  was wondering if we must all replace MochiKit for Dojo to do this
  paradigm.


 Furthermore, doesn't Comet/http push/long polling require some
  modifications to your *server* to do it right?? (e.g. event driven
  instead of multithreaded ??)


 I don't see how Dojo or any Javascript library can do it all by
  itself.

  Sincerely,

  Chris

  


--~--~-~--~~~---~--~~
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: Trac tickets and code submissions

2008-02-24 Thread Bob Ippolito

I watch trac with my newsreader, but for the widest exposure
mentioning them on the list helps.

On Sun, Feb 24, 2008 at 12:48 AM, Per Cederberg [EMAIL PROTECTED] wrote:

  Hi,

  Just a simple question (for Bob I guess):

  Does someone monitor ticket submissions to trac.mochikit.com? Is it
  the best way to submit patches and new stuff for MochiKit, or should I
  also cross-post to this list?

  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: I'm having a problem with BindMethods

2008-02-05 Thread Bob Ippolito

I think you're confused. self is not defined. You want to be using this.

On Feb 4, 2008 11:59 PM, Akari no ryu [EMAIL PROTECTED] wrote:

 self is a property of the pseudo classes in Javascript, similar to
 this.
 I possibly should have added that if I comment out the bindMethods
 part, everything works as expected.

 On Feb 5, 7:55 am, Bob Ippolito [EMAIL PROTECTED] wrote:
  Card = function(value, suit, orientation, set)
  {
 MochiKit.Base.bindMethods(self);
 
  ^^ self isn't defined here.


 


--~--~-~--~~~---~--~~
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: I'm having a problem with BindMethods

2008-02-04 Thread Bob Ippolito

Card = function(value, suit, orientation, set)
{
   MochiKit.Base.bindMethods(self);

^^ self isn't defined here.

On Feb 4, 2008 10:54 PM, Akari no ryu [EMAIL PROTECTED] wrote:

 I have three files.
 var deck = new Deck();
 loadPage = function()
 {
 var postRequest = new
 MochiKit.Async.doSimpleXMLHttpRequest('deck.php', {'method':'post'});
 postRequest.addCallback(
 function(request)
 {
 deck.load(request.responseXML);
 }
 );
 }

 function debug(obj)
 {
 str = {;
 for(i in obj)
 {
 str+=\t+i+:+obj[i]++\n;
 }
 str+= };
 logDebug(str);
 }

 MochiKit.Signal.connect(window, 'onload', loadPage);

 which builds a Deck object from the class

 Deck = function()
 {
 this.set = null;
 this.cards = [];
 this.md = MochiKit.DOM;
 }

 Deck.prototype.load = function(doc)
 {
 var xml = doc.documentElement;
 this.set = xml.getAttribute('set');
 var cardNodes = xml.getElementsByTagName('card');
 for(i=0; icardNodes.length; i++)
 {
 card = new Card(
 cardNodes[i].getAttribute('value'),
 cardNodes[i].getAttribute('suit'),
 cardNodes[i].getAttribute('orientation'),
 this.set
 );
 this.cards.push(card);
 }
 this.addCards();
 }

 Deck.prototype.addCards = function()
 {
 log(here)
 }

 The load method of Deck should instantiate Card objects

 Card = function(value, suit, orientation, set)
 {
 MochiKit.Base.bindMethods(self);
 this.md = MochiKit.DOM;
 log(this);
 this.value = value;
 this.suit = suit;
 this.orientation = orientation;
 this.set = set;
 }

 Card.prototype.getXMLString = function()
 {
 return 'card value='+this.value+' suit='+this.suit+'
 orientation='+this.orientation+'/';
 }

 Card.prototype.rotate=function()
 {
 this.orientation=(!this.orientation);
 }

 Card.prototype.clone=function()
 {
 return new Card(this.value, this.suit, this.orientation, this.set);
 }

 Card.prototype.getSuit = function()
 {
 return this.suit;
 }

 But the log is reporting this, for the class, as Object Window, not
 Object Object. I've been racking my brains over this one for a while
 now. Any ideas?

 


--~--~-~--~~~---~--~~
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: deferred callbacks that throw errors

2008-01-23 Thread Bob Ippolito

On Jan 23, 2008 9:07 PM, SimonS [EMAIL PROTECTED] wrote:

 Hi,

 I'm curious about the effect of the following code:

   var d  = new Deferred();
   d.addCallback(function() { alert('f');  throw new
 GenericError('foo'); });
   d.addErrback(function() { alert('e'); });
   d.addCallback(function() { alert('s'); });
   d.callback('success');

 The result I observe is that all three alerts fire, in the order 'f',
 'e', 's'.  This happens even though the first callback (f) throws an
 exception.  My question is why is the last alert fired?

 The docs say that a callback that throws an exception will put the
 deferred into an error state.  Since the deferred transitions to an
 error state, why does it continue calling the 'success' chain?

 Is there a simple way to abort the callback chain from one of the
 callbacks?

It continues calling the success chain because the errback doesn't
return an error or raise an exception.

-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: Shouldn't doXHR default to POST instead of GET to be proper?

2008-01-21 Thread Bob Ippolito

On Jan 21, 2008 12:56 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:



 On Jan 21, 1:16 am, troels knak-nielsen [EMAIL PROTECTED] wrote:

  That depends on how you use it. The assumption is, that you are
  pulling data with doXHR. If you want to push data, you should specify
  the method. Most other HTTP-agents also default to using GET, and only
  use POST, when explicitly told to. (Take the browser, for example)

 I thought loadJSON was for pulling from server and doXHR was for
 pushing to server.  I didn't know doXHR could be used for both.

 I suppose you'll say that doXHR is needed when people do NOT want to
 pull data from server in JSON format?

doXHR is the primitive operation used by all XMLHttpRequest-based
operations, including loadJSON.

-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: How prepend a prefix like /myapp/ to all URLs in MochiKit/Javascript?

2008-01-15 Thread Bob Ippolito

Write your own function? I guess all XHR requests go through doXHR at
some point, so you could swap it out with something else. Something
like this might work:

MochiKit.Async._old_doXHR = MochiKit.Async.doXHR;
doXHR = MochiKit.Async.doXHR = function (url) {
return MochiKit.Async._old_doXHR.apply(MochiKit.Async,
extend(['/myapp/' + url], arguments, 1));
};

-bob

On Jan 14, 2008 11:42 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 I'm happily using MochiKit in TurboGears.   TurboGears has a nice
 setting to add prefixes to all URLs (server.webpath).

 For example, for server.webpath = /myapp:

 /a - /myapp/a
 /b - /myapp/b

 etc.

 This does *not* seem to affect Javascript code.

 Anyway to do something similar in my MochiKit/Javascript code?

 Chris

 


--~--~-~--~~~---~--~~
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: 'this' in Draggable callback

2008-01-13 Thread Bob Ippolito

On Jan 13, 2008 11:35 AM, James [EMAIL PROTECTED] wrote:

 Hi all, I'm something of a newcomer to MochiKit to forgive me if this
 is a silly question.

 When using Signal's 'connect' function to add signal callbacks I'm
 using the form:

 var obj = new MyObj;
 connect(window, onload, obj, 'init');

 So that 'this' still refers to obj in the init function.

 However, I'm also using custom callbacks for a Draggable I'm creating,
 e.g.:

 var dr = new Draggable($('drag'), {
 'onchange': this.dragMoved
 }

 In the MyObj.dragMoved function I need access to the obj object, but
 'this' refers to the signal source.

 I tried:
 'onchange': partial(this.dragMoved, this)
 adding a 'self' parameter onto MyObj.dragMoved, but self seemed to be
 a copy of 'this' as it was when I connected the callback, rather than
 the live version - a closure in other words.

 Is there a way for me to get at the live obj instance in this
 situation?

Yeah, use bind instead of partial.

-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: Firefox Issues?

2008-01-02 Thread Bob Ippolito

getElement(loginForm) finds an element with an id of loginForm. IE
confuses name and id, other browsers don't. You don't have any
elements with id=loginForm in your markup. Try using
getElement(lfForm).

-bob

On Jan 2, 2008 3:45 PM, infringer [EMAIL PROTECTED] wrote:

 Hi,

 I developed my site using Internet Explorer v7.  Now I come to find
 out it doesn't work with firefox.

 in my Javascript I have:

 self.form = getElement(loginForm);
 self.form.login.focus();

 and I keep getting self.form has no properties error message in the
 Firefox Error Console.

 Granted, this issue isn't that big a deal as it just isn't focusing.
 But I have other places where I get the exact same error message
 self.form has no properties

 Here is the HTML for the form:

 form name='loginForm' action='process.html' method='POST'
 id=lfForm
 div class=fieldLabelLogin:/div
 div class=fieldEntry
 select name='login'
 option A Bunch of Options /option
 /select/div
 div class=fieldLabelPassword:/div
 div class=fieldEntryinput type='password' name='pw' size=15
 maxlength=100 value = //div
 div id=lfButtoninput type='submit' name='lfSubmit' value=Login
 class='null'/div

 input type=hidden name=validbrowser value=false
 /form

 Can anyone provide advice/help?

 Thanks,
 -David

 


--~--~-~--~~~---~--~~
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: Async request problem on Safari

2007-12-29 Thread Bob Ippolito

Have you tried using doXHR with the mimeType: 'text/xml' option? Take
a look at the ajax_tables or interpreter examples for usage.

On Dec 29, 2007 9:50 AM, Steve Zatz [EMAIL PROTECTED] wrote:

 No matter what I put in that XML declaration, Safari only returns
 something for responseText (tested on both Leopard and Windows).  I
 tried the DOMParser suggestion but I can't get it to work either --
 there must be something wrong with the xml string but I can't figure
 it out (yet).  Thanks again for taking a look at this and for your
 suggestions.

 Steve


 


--~--~-~--~~~---~--~~
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: callLater and this

2007-12-20 Thread Bob Ippolito

On 12/20/07, Ian Lewis [EMAIL PROTECTED] wrote:
 Is it intentional that the callLater() function causes the 'this' reference
 to get scrapped?

Has nothing to do with MochiKit, JavaScript doesn't have bound methods
like Python does. The binding of this is done by the method call
syntax. It would be impossible to preserve it unless the function was
wrapped.

See MochiKit.Base.{bind,method,bindMethods} for the typical workarounds, also:
http://bob.pythonmac.org/archives/2005/07/06/this-sucks-in-javascript/

-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: callLater and this

2007-12-20 Thread Bob Ippolito

On 12/20/07, Ian Lewis [EMAIL PROTECTED] wrote:
 Thanks bob, I guess it's been about 8 years. Good to talk to you again.

High school feels a lot longer ago than that :)

 Tricky. I suppose you would run into this pretty much any time you pass
 around foo.bar when bar bound (or not) to the object foo as you wouldn't be
 able to do the call with this syntax. If your blog post is right then it
 looks like the only way to do call with this explicitly calling the
 function via the object in code.

Welcome to JavaScript.

That's pretty much what bind does, but Function.prototype.call and
Function.prototype.apply let you jigger this for a given call.

foo.bar(a, b) is the same as foo.bar.apply(foo, [a, b]) or
foo.bar.call(foo, a, b).

 Anyway, changing the test code to

  test.init = function() {
createLoggingPane(true);
callLater(3.0, bind(test.myfunc, test));
  }

 works. It's cute how bind returns a function that calls your function but
 goes out and finds the this for you first. Pretty useful hack.

Well you give it 'this' as the second argument, it doesn't do all that
much magic.

bind(test.myfunc, test) is equivalent to function () { return
test.myfunc.apply(test, arguments); }

-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: Problem in IE not in Firefox - loadJSONDoc

2007-12-19 Thread Bob Ippolito

On 12/19/07, JS [EMAIL PROTECTED] wrote:

 I have the Javascript code which is located here:  
 http://pastebin.com/m6d9fe26c

 It works 100% of the time when I use Firefox for my browser, but
 doesn't give expected results all the time with IE.  The problem
 occurs after line 12.  Here is an overview of what I'm doing.

 I have an INPUT field where I'm capturing the ENTER key press and
 calling an 'updateMethod'.  When the 'updateMethod' completes, I want
 to call a 'revertMethod' which will change the INPUT field back to the
 HTML that it was before.  (It got changed to an INPUT field when the
 user double-clicked on it).  The update is working 100% of the time,
 regardless of the browser.  After the update, it seems that at times,
 with IE that the 'revertMethod' is not called.  But, I don't know how
 to debug this with IE.  As I said, it works in Firefox where I use
 Firebug and the logger for debugging.

 I'm very new to Javascript programming and the whole callback thing,
 and am wondering if there is a problem with the way that I have a
 second loadJSONDoc embedded inside a callback from a previous
 loadJSONDoc.

 Or, maybe I'm going about the entire thing all wrong.  Any advice on
 how to debug in IE (MochiKit 1.3) or similar experiences with
 loadJSONDoc would be appreciated.

http://groups.google.com/group/mochikit/browse_thread/thread/3cd6439ac43b1909/4d1aa3d71d464abd?#4d1aa3d71d464abd

-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: New INPUT short-hand functions?

2007-12-17 Thread Bob Ippolito

It still wouldn't work because you need the arguments object, not
arguments[0], for the call to apply.

My personal preference would be to use merge because it wouldn't
mutate the input object you give it, but there are potential
efficiency concerns with all that extra overhead. The original
solution was probably fine. MochiKit isn't a replacement for
JavaScript, you shouldn't try and wedge it in everywhere just because
it might be possible :)

-bob

On 12/17/07, Kevin Damm [EMAIL PROTECTED] wrote:

 Oops, that should probably be arguments[0]


 On Dec 17, 2007 2:00 PM, Kevin Damm [EMAIL PROTECTED] wrote:
  Maybe use MochiKit.Base.merge or MochiKit.Base.update:
 
  function CHECKBOX() {
   return INPUT.apply(this, update(arguments, {'type': checkbox}));
  }
 
   - Kevin
 
 
  On Dec 17, 2007 1:30 PM, machineghost [EMAIL PROTECTED] wrote:
  
 
   I recently found myself doing this a lot:
   var a = INPUT({type:textbox});
   var b = INPUT({type:checkbox});
   var c = INPUT({type:hidden});
   etc.
  
   So I wanted to make short-hand functions like CHECKBOX and HIDDEN
   which would work exactly like INPUT, only with a pre-specified type.
   At first I thought I could do this:
   CHECKBOX = createDOMFunc(input, {type:checkbox});
  
   but that eliminated all other attributes (since the {type:checkbox}
   replaced my attributes argument).  I played around a bit, and
   eventually found that I could make it work with:
   function CHECKBOX(){
   arguments[0][type] = checkbox;
   return INPUT.apply(this, arguments);
   }
  
   But that doesn't seem very MochiKit-ish to me, so I was wondering if
   there was a cleaner way to do the above using bind or partial or
   something.  Also, I was curious as to how people feel about these
   short-hand functions, and whether or not they'd be useful enough to
   include in MochiKit.DOM.
  
   Any thoughts/feedback would be appreciated.
   Jeremy
  
  
  
   So my question is, is th

  
 

 


--~--~-~--~~~---~--~~
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: Usage of Selector (or bug?)

2007-12-14 Thread Bob Ippolito

It looks like the example is probably incorrect, it's marked as a
constructor so you may need to use the new operator.

var selector = new Selector(#someelementid);

On 12/14/07, Glin [EMAIL PROTECTED] wrote:

 Hi

 I tried to use selector example from Mochikit documentation:

 var selector = MochiKit.Selector.Selector('#someelementid');

 But I got this error:

 this.parseExpression is not a function

 It is on line 37 in Selector.js.

 Should I initialize something before I use this module? Or is it a
 bug?



 PS: This module looks incredible, if I was able to use it, it could
 save me a lot of pain and the resulting code would be much nicer.


 


--~--~-~--~~~---~--~~
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: What is the purpose of __class__?

2007-11-28 Thread Bob Ippolito

It's only used for introspection. Some of the repr's use it, the ones
that don't probably should. It's not otherwise very interesting.

-bob

On 11/28/07, Jason Bunting [EMAIL PROTECTED] wrote:




 I see this convention being used but don't understand why it exists:



 __class__



 Is it simply a Pythonic type of convention that isn't being used currently?
 What is the point of it and how can it be beneficially used?



 Thanks,
  Jason Bunting


  


--~--~-~--~~~---~--~~
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: Looser binding with bind() and more generic signalling

2007-11-20 Thread Bob Ippolito

On 11/18/07, Per Cederberg [EMAIL PROTECTED] wrote:

 #1. Is there a way to do late binding with MochiKit.Base.bind? I.e.
 allowing function names to be resolved when the returned function is
 called, rather than when bind() is called. See example below:

 obj = {
 a: function() { return a; },
 }
 var test = MochiKit.Base.bind(a, obj);
 test() == a
 obj.a = function() { return b; }
 test() == b (currently MochiKit returns a here)

 It is easy enough to modify the MochiKit.Base.bind(), but it would of
 course break semantic backwards compability a bit.

I gave it a shot and it definitely breaks backwards compatibility in a
way that the tests fail. I won't be doing this, but you can do this
with forwardCall.

 obj = {a: function () { return a; }}
[object Object]
 test = bind(forwardCall(a), obj)
function () {...}
 test()
a
 obj.a = function () { return b; }
function () {...}
 test()
b

 #3. With a few quick hacks to set class and function names on object
 functions I've been able to implement JavaScript stack traces. And
 combined with logging, this has proven extremely powerful for
 debugging issues in the application.

 Is there something for stacktraces already in MochiKit? Would it be
 welcomed as a patch?

I've done things like this before, but not in MochiKit. I started
caring a lot less about debugging tools since Firebug came out :) A
patch would be good.

-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: 1.4, again

2007-11-06 Thread Bob Ippolito

A release manager would be responsible for deciding when to do
releases, as well as to make sure everything is up to snuff... which
would probably mean that they'd spend a lot of their time reviewing
code and docs, probably fixing some of it personally (especially
docs). I think we're pretty solid on most things, but all of the new
stuff still needs work (Selector, and the Scriptaculous stuff). I'm
tempted to do a release without those things, but it seems that most
people are using one or the other by now so that's not really an
option.

I've had a couple people express interest so far, but I'm in Seoul
right now for a conference and I'm having a hard enough time keeping
up with work stuff so I will probably get to that in a week or two
after I get back to SF.

-bob

On 11/7/07, JonR800 [EMAIL PROTECTED] wrote:

 That begs the question, what's required of a release manager for MK?

 On Oct 29, 4:23 pm, Bob Ippolito [EMAIL PROTECTED] wrote:
  There's no need to fork the project, I would gladly hand over SVN
  access to someone who wants to step up as a release manager.
 
  -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: 1.4, again

2007-10-29 Thread Bob Ippolito

There's no need to fork the project, I would gladly hand over SVN
access to someone who wants to step up as a release manager.

-bob

On 10/29/07, gsteff [EMAIL PROTECTED] wrote:

 I don't use Mochikit, but like the library, and check in on the
 newsgroup now and then.  If a lot of people want to see new features
 added to Mochikit, or at least an acknowledgement that the new
 features already added are stable (via a new release), the normal
 solution I think is for someone to fork the project.

 Greg

 On Oct 17, 11:58 am, Arnar Birgisson [EMAIL PROTECTED] wrote:
  On 10/17/07, Jonathan Ellis [EMAIL PROTECTED] wrote:
 
   On Oct 16, 3:20 pm, Arnar Birgisson [EMAIL PROTECTED] wrote:
Most people are in one of two situations:
 
1. Already using MK. If it's working and you're happy with it, why do
you need a release? If it is not, a release won't help much.
 
   That's the thing, the cutting edge is a moving target and those of us
   who started using MK 1+ years ago have seen our requirements get
   steeper but MK not keep pace.  So a lot of us are in the position of
   it's working, we have code invested in it, but we're NOT really happy
   with it anymore.
 
  Sadly, that's always a danger when investing in software, free or not.
  I've on many occasions been in the situations where there was even a
  support contract in place.
 
  The good thing about open source is that in that case you are able to
  extend it with the things you need (or pay someone to do it).
 
   Before you start frothing at the mouth, I'm not claiming Bob or you or
   anyone else owes me anything.
 
  My apologies, I regret that the tone in my previous post implied that
  I thought so. I just felt we were going in circles discussing the same
  thing over and over.
 
   Although a little communication is kind
   of an implicit obligation when you take something like this public,
   it's not hard to tell what it means in this case.
 
  Absolutely, and I believe that obligation has been met by the MK
  maintainers (btw I don't consider myself one of them).
 
  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: twoDigitFloat bug

2007-10-08 Thread Bob Ippolito

That's how floats work, 568.80 is represented internally as (roughly)
567.7999. numberFormatter rounds though, you can use
numberFormatter(#.##)(568.80) which should give you what you want.

On 10/8/07, Pedro Belo [EMAIL PROTECTED] wrote:

 Hey guys,

 I'm running into something that looks like a floating point problem,
 but I'm not sure about what can be done about it.

 The thing is: twoDigitFloat(568.80) returns 568.79. Just tested
 against the trunk, too.

 I've created a ticket in case anyone comes with a solution:
 http://trac.mochikit.com/ticket/275

 Thanks,
 Pedro


 


--~--~-~--~~~---~--~~
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: How to get Signal.connect code rendered via .innerHTML replacement to work?

2007-10-05 Thread Bob Ippolito

On 10/4/07, John Lorance [EMAIL PROTECTED] wrote:

 The Problem:
 I have a button on a page that results in getting HTML back from the
 server which contains something like the following (result['content']
 (below) contains the following):


innerHTML doesn't execute script. You could try something like this:

var elem = getElement(target_id);
elem.innerHTML = result['content'];
var script_tags = getElementsByTagAndClassName(script, null, elem);
for (var i = 0; i  script_tags.length; i++) {
eval(scrapeText(script_tags[i]));
}

I'm not sure if that works in all of the browsers, make sure to give
it a try in the ones you care about.

-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: Activity

2007-10-05 Thread Bob Ippolito

On 10/3/07, scipio [EMAIL PROTECTED] wrote:



 On Aug 18, 11:59 am, Beau Hartshorne [EMAIL PROTECTED] wrote:
  On 18-Aug-07, at 8:44 AM, Lee Connell wrote:
 
   Mochikit hasn't seen any activity in the revision history at least
   since 06, is mochikit fading?
 
  We're pretty busy with our own projects, and haven't had much time to
  tag a release. /trunk is very stable, and is updated with features
  and bugfixes regularly:
 
  http://trac.mochikit.com/browser/mochikit/trunk

 Desparately short sighted: if you leave a web site
 untouched for a year, most people will assume its
 dead and move on.   In discussions about JS client
 frameworks I've already seen several comments suggesting
 that MK development is dead.

 How hard can it be to tag the repository and
 update a couple lines of text on a web page?


It's enough of a hassle. Honestly, I don't care if anyone uses
MochiKit or anything else, they should pick whatever works for them.
MochiKit is not a marketing exercise, I don't do consulting and I'm
not terribly interested in speaking about JavaScript at conferences
right now. We use it, it works great for us. I'd like to do a release,
but I care a lot more about what my company is actually working on
right now. MochiKit hasn't changed much lately because we got it to
the point where it does what we want it to do and we haven't needed a
whole lot else from it. The big mistake that I made was accepting a
bunch of functionality that we had no intention of using internally,
which is what's holding up the release because it doesn't pass quality
control as far as code audit and docs go. I'm not really comfortable
tagging what's in there as a release in its current state.

If someone is truly interested in being the release manager for
MochiKit they can step up and I'd be more than happy to give them full
reign. I'll even give them a job (interview, anyway) if they want to
move to San Francisco and do front-end work for us also :)

-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: $ in jQuery, Prototype and Mochikit

2007-09-02 Thread Bob Ippolito

MochiKit doesn't actually use $, it's just an alias for getElement
that we export for the user's convenience. You can load whatever
library you want after MochiKit and let it take over use of $, nothing
will break.

-bob

On 9/2/07, jack.tang [EMAIL PROTECTED] wrote:

 Hi, all

 I blogged one case in my blog (http://jack.lifegoo.com/?p=163) which
 described the complaint of $ in jQuery, Prototype and Mochikit,
 could you please take it consider and reduce the conflicts?

 Thanks.

 /Jack


 


--~--~-~--~~~---~--~~
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: Comparing dates

2007-08-28 Thread Bob Ippolito

On 8/28/07, grum [EMAIL PROTECTED] wrote:

 Hi everyone,

 I'm having problems comparing the following:

 isoTimestamp(2007-08-13T04:00:00+00:00)

 which gives me:

 Mon Aug 13 2007 00:00:00 GMT-0400 (EDT)

 and:

 Date()

 which (right now) gives me:

 Tue Aug 28 2007 16:14:12 GMT-0400 (EDT)

 ie. isoTimestamp(2007-08-13T04:00:00+00:00)  Date() is returning
 false.

 I think it's something to do with the lack of quotes around the result
 of isoTimestamp - though quite what that means i'm not sure.  Please
 someone help me out, i really need to be able to compare these dates.

JavaScript's built-in comparison operators are no good for comparing
objects, only strings and numbers. This is why MochiKit.Base.compare
exists.

-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: Deferred.addCallbackMethod

2007-08-22 Thread Bob Ippolito

On 8/22/07, Giulio Cesare Solaroli [EMAIL PROTECTED] wrote:

 Hello,

 using the excellent MochiKit.Async module, I find myself writing the
 following code over and over:

 dererred.addCallback(MochiKit.Base.method(anObject, 'aMethod'), aParam, ...);

 It look like it would be nice to add a 'addCallbackMethod' to the
 Deferred class in order to be able to write the above statement like
 this:

 deferred.addCallbackMethod(anObject, 'aMethod', aParam, );


Well if you're importing MochiKit then you can just say
method(anObject, 'aMethod') instead of MochiKit.Base.method, and then
it's almost just as short as addCallbackMethod. I don't really see a
reason to add more API.

-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: callLater and IE

2007-08-21 Thread Bob Ippolito

On 8/21/07, Jonathan Marshall [EMAIL PROTECTED] wrote:

 Hi,

 I'm not sure if this is a bug in Mochikit, or my error.

 The following do not work in IE 6:

 script
 callLater(1, window.print);
 callLater(2, alert, 'drink beer');
 /script

 yet these do:
 script
 function f() {
 window.print();
 }
 function g() {
 alert('drink beer');
 }
 callLater(1, f);
 callLater(2, g);
 /script

 Works beautifully in Firefox though.Tried with Mochikit 1.3.1 and a
 recent dump from SVN.

Some of these built-in methods and functions aren't actual JavaScript
functions and aren't compatible with Function.prototype.apply, so
using MochiKit directly on them may not work. I think there's a
workaround for it in MochiKIt that makes it work in Firefox and maybe
Safari but I guess that workaround doesn't work properly in IE6.

-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: Why No DL/DT/DD Functions?

2007-08-03 Thread Bob Ippolito

They are not deliberately left out. If a patch were made to the
documentation and code it'd be applied.

-bob

On 8/3/07, machineghost [EMAIL PROTECTED] wrote:

 Perhaps it'd be more helpful if I rephrased this question:
 If someone (ie. me) were to write createDOM shorthand functions for
 DL, DT, and DD, would whoever maintains Mochikit add them?  Or are
 those functions for these elements deliberately left out of the
 library for some reason?

 Jeremy
 On Jul 31, 12:14 am, machineghost [EMAIL PROTECTED] wrote:
  The other day I noticed that there is no createDOM shorthand function
  for any of the definition list tags (DL, DT, and DD).  Anyone know why?


 


--~--~-~--~~~---~--~~
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: Async status success return codes question

2007-08-01 Thread Bob Ippolito

Implement a workaround. Just write an errback that turns 2xx into a
successful response, that way your code will still work if the
behavior eventually changes.

On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 So is this yet another thread on success codes that ends without
 consensus or a final word on success code meaning in MochiKit?

 Obviously I would prefer it if MochiKit treated all 2** as successes
 but if the decision is that this wont change then I'll just implement
 the work around and take it of my TODO list.

 So Bob can you provide the final word?

 Regards, Simon Cusack


 


--~--~-~--~~~---~--~~
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 Development

2007-07-18 Thread Bob Ippolito

On 7/18/07, Jason Bunting [EMAIL PROTECTED] wrote:


 I *am* curious as to the effort to get us to an official '1.4' release -
 seemed like there was a bit of momentum a few weeks/months back to get all
 bugs fixed and get it shipped, but then it seemed to die.

I think that most or all of the bug fixes are done, IIRC it's a matter
of auditing everything and making sure the docs are good. I've been
really busy, and since MochiKit works as-is for us (svn trunk
obviously doesn't bother me) I haven't needed to devote much time to
it.

I understand that this bothers some people, but I didn't develop
MochiKit to do consulting and my company doesn't really do anything
that would benefit from MochiKit being more popular. I also don't need
a job and I haven't seen any AJAX conferences in interesting locations
lately ;)

 Other than that, I think MK is near-perfect and find it interesting how
 people seem to feel that if a product/technology/etc. isn't constantly being
 developed, it is somehow not that great or not worth using; if MochiKit
 fulfills the measure of its creation (i.e. if its current state meets the
 goals set out for its original design/purpose), then why does it need to be
 continually developed? Some things just mature and are then good enough
 unless major bugs pop up.

That's more or less how I feel about it. I do plan on getting to a 1.4
release, but I've got all of these other internal releases to worry
about before that happens :)

-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: create form in document

2007-07-16 Thread Bob Ippolito

On 7/16/07, MerlinTheCat [EMAIL PROTECTED] wrote:

 Hi, I'm well versed in JS - but I've been struggling to understand
 MochiKit for a couple of days... help from anyone who can clear my
 brainblock would be appreciated. Thanks.

 I'm trying to add a form on the page dynamically. The H1 and [object
 Object] form? gets displayed on the page... but I can't see the form
 or access any of it's fields or submit it???

 Here's my code:


 MochiKit.DOM.withWindow(self.window, MochiKit.Base.bind( function() {

 var doc = MochiKit.DOM.currentDocument();
 MochiKit.DOM.appendChildNodes(doc.body, H1(null,This gets added
 OK));

 var formObj = MochiKit.DOM.FORM({id:myForm,
 action:test01.asp, method:post}, {inputs: [{type:text,
 id:field1, name:field1, value:newval}, {type:submit,
 name:mySubmit, value:mySubmit}]});

 MochiKit.DOM.appendChildNodes(doc.body, formObj);

 alert(doc.body.formObj.field1);  // this indicates undefined?
 alert(doc.formObj.field1);  // this indicates undefined?

 }, this));

That's because the code you wrote doesn't make any sense. {inputs: [
... ]} isn't going to do anything. You need to do the same thing
you're doing with FORM, except with INPUT.

FORM(attrs, INPUT(attrs), INPUT(attrs), ...)

-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: Can't get 'this' to point to the right object

2007-07-09 Thread Bob Ippolito

On 7/9/07, TiNo [EMAIL PROTECTED] wrote:
 Hi,

 I am having another problem with 'this' again.
 I have to classes (better said, that's how I would like them to behave),
 EditGrid and EditCell:
 ---
  var EditGrid = function (base_url,target_id) {
 bindMethods(this);
 this.base_url = base_url;
 this.target_id = target_id;
 [...]
 this._createGrid();
 connect(window.document,'onkeydown',this._handleKey);
 }

 EditGrid.prototype = {
[methods]
 }

 var EditCell = function (el,type,special_edit) {
 bindMethods(this);
 this.cell = el;
 this.type = type;
 this.special_edit = special_edit;
 info = el.id.split('_');
 this.column = info.pop();
 this.id = info.pop();
 }

 EditCell.prototype = {
 [methods...]
 }
 ---
 When both get 'instantiated' from a javascript block on the html-page there
 is no problem. 'this' refers in both cases to them selfs as an object. But
 when I try to 'instantiate' one of them from the same javascript file (be it
 from the bottom line of the script, or calling EditCell from EditGrid), this
 refers to 'window'. What can I do about this?

There's a bug with the interaction between bind and connect. You
either need to upgrade to MochiKit from SVN, or you need to write the
connect as:

connect(window.document,'onkeydown',this, '_handleKey');

-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: 'this' and addCallbacks

2007-07-09 Thread Bob Ippolito

On 7/9/07, kael [EMAIL PROTECTED] wrote:

 This doesn't work.  When the callback, dataReciever, is called it
 doesn't know what 'this' is any more.
 I want dataReciever to update the object and then call
 this.showRecord.

 SBP.prototype.dataReceiver = function(data) {
 // data is an array of (id,text) things
 alert(this.divID + ' dr') // here,
 this.divD is undefined
 this.data=data;
 this.idx = 0;
 this.showRecord(idx);
 };

 SBP.prototype.refreshRecords = function (){
 epReq=loadJSONDoc(this.refreshJSON);
 epReq.addCallbacks(this.dataReceiver,alertFailed);
 alert(this.divID) //
 this.divD here is correct
 };

 Does anybody care to point out the problems in the design?

Two major problems in the design.

1. Your code expects something asynchronous to happen as soon as the
next line of code executes. Asynchronous code by definition doesn't
work like that. Even if the code wasn't otherwise broken,
alert(this.divID) will never work where you put it. You can only
access it after the callback has happened, which means you either make
a second callback or you add it to the end of the code in your
existing callback.

2. JavaScript doesn't have bound methods. You can't use
this.dataReceiver as a callback. You can use method(this,
dataReceiver) though, which will do the right thing.

-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: 'this' and addCallbacks

2007-07-09 Thread Bob Ippolito

On 7/9/07, Bob Ippolito [EMAIL PROTECTED] wrote:
 On 7/9/07, kael [EMAIL PROTECTED] wrote:
 
  This doesn't work.  When the callback, dataReciever, is called it
  doesn't know what 'this' is any more.
  I want dataReciever to update the object and then call
  this.showRecord.
 
  SBP.prototype.dataReceiver = function(data) {
  // data is an array of (id,text) things
  alert(this.divID + ' dr') // here,
  this.divD is undefined
  this.data=data;
  this.idx = 0;
  this.showRecord(idx);
  };
 
  SBP.prototype.refreshRecords = function (){
  epReq=loadJSONDoc(this.refreshJSON);
  epReq.addCallbacks(this.dataReceiver,alertFailed);
  alert(this.divID) //
  this.divD here is correct
  };
 
  Does anybody care to point out the problems in the design?

 Two major problems in the design.

 1. Your code expects something asynchronous to happen as soon as the
 next line of code executes. Asynchronous code by definition doesn't
 work like that. Even if the code wasn't otherwise broken,
 alert(this.divID) will never work where you put it. You can only
 access it after the callback has happened, which means you either make
 a second callback or you add it to the end of the code in your
 existing callback.

Sorry, I misread the code. It looked like you were setting the divID
in the callback. Ignore this part.

 2. JavaScript doesn't have bound methods. You can't use
 this.dataReceiver as a callback. You can use method(this,
 dataReceiver) though, which will do the right thing.

This still applies though.

-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: Async status success return codes question

2007-07-06 Thread Bob Ippolito

On 7/5/07, Karen J. Cravens [EMAIL PROTECTED] wrote:

 On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote:
  with (the ones that you actually run into in the wild). It's easy to

 Given the increasing popularity of REST, seems pretty likely you'll
 start running into a wider range of response codes in the wild.

 It's kind of disturbing to learn it's that noncompliant; we haven't
 settled on a library yet, but Mochikit was the front-runner for me.
 Now I'm back to I dunno, let's put all the names in a hat and pick
 one, since Wirebird makes use of pretty much the full range of HTTP
 responses.

As demonstrated it's effectively three lines of code to do whatever
you want to do with HTTP status codes, and you only have to write it
once. If that really makes such a difference, then I doubt MochiKit is
the right choice for you. There are many cases where you actually have
to write code, but MochiKit's behavior is well documented so at least
you know what it's going to be doing.

-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: Async status success return codes question

2007-07-06 Thread Bob Ippolito

On 7/6/07, Karen [EMAIL PROTECTED] wrote:
 On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote:
  As demonstrated it's effectively three lines of code to do whatever
  you want to do with HTTP status codes, and you only have to write it
  once. If that really makes such a difference, then I doubt MochiKit is
  the right choice for you. There are many cases where you actually have
  to write code, but MochiKit's behavior is well documented so at least
  you know what it's going to be doing.

 Yes, I saw the example, but it's more of a philosophy issue... it's a
 matter of the right tool for the task. I need a stickler-for-the-rules
 RFC-compliant library; Mochikit seems to have a more pragmatic
 approach. This works 99% of the time, but I'm that obscure 1%.


It works 100% of the time. If you're doing something obscure with
status codes (anything obscure, even successful codes that aren't
2xx), you need to use an extra three lines of code in this case. That
doesn't mean it's broken.

-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: Async status success return codes question

2007-07-06 Thread Bob Ippolito

On 7/6/07, Karen [EMAIL PROTECTED] wrote:
 On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote:
  It works 100% of the time. If you're doing something obscure with
  status codes (anything obscure, even successful codes that aren't
  2xx), you need to use an extra three lines of code in this case. That
  doesn't mean it's broken.

 It means it's not RFC-compliant out of the box. I'm not saying that's
 a bad thing overall (the other 99% of the time, you don't want
 overhead for bits that almost no one uses), I'm just saying it's a bad
 fit for me.

 Three lines of code for this fix and that does start to add up; at a
 certain point it becomes more efficient to start with a more low-level
 library rather than try to impose a new design philosphy on a more
 advanced one.

Given that you can write your own functions, and those functions can
call other functions, you only have to do it once.

-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: Async status success return codes question

2007-07-05 Thread Bob Ippolito

On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 I have been working with Async to build an inhouse web app, we have
 ended up using the return codes to implement some interesting
 behaviour in our clients.

 MochiKit is just one of the clients that uses the web service and some
 of our other processes (robots essentially) look for return codes to
 act upon.  One of these codes is 202 - Accepted.  We use this in
 response to requests that fire off long running processes in the
 server.  The server responds with a 202 saying that it is now running
 the process and includes a location header to indicate where the
 client should go to get updates on the current status of the process.

 By default MochiKit doesn't treat a 202 as a success.

MochiKit is written mostly with practical considerations in mind, and
it only knows how to handle the specific success codes that it deals
with (the ones that you actually run into in the wild). It's easy to
make it do what you want though... something like this:

function http_2xx_ok(err) {
if (err instanceof XMLHttpRequestError  err.number = 200 
err.number  300) {
return err.req;
}
throw err;
}

var d = doXHR(...).addErrback(http_2xx_ok).addCallback(...);

-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: 'this' gets overridden on every function call

2007-06-20 Thread Bob Ippolito

On 6/20/07, TiNo [EMAIL PROTECTED] wrote:

 With the following code (shortend):
 --
 var EditGrid = function (base_url, target_id) {
 bindMethods(this);
 this.base_url = base_url;
 this.target_id = target_id;
 this.editing = false;
 this.direction = 6; //forward, see your numpad
 this.editcell = null;

 this.render();
 }

 EditGrid.prototype = {

 render : function(params) {
 params = params || {};
 params = eval(params);
 params['tg_random'] = new Date().getTime();
 params['tg_format'] = json;
 var d = loadJSONDoc(this.base_url + '/get_data', params);
 d.addCallback(this.createGrid);
 return d;
 },

 createGrid : function(response) {
 var grid = Widget.editgrid.render(this.target_id, response);
 swapDOM(this.target_id, grid);
 connect(window,'onkeydown',this.handleKey);
 },

 editCell : function(e) {
 [...]
 },

 handleKey : function(e) {
 [...]
 if(e.key()['string'] == 'KEY_ESCAPE')
 {
 this.abort()
 e.stop()
 }
 [...]
 },

 abort : function(e){
 var editcell = this.editcell;
 if(!this.editing) return;
 
 swapDOM(editcell.firstChild,document.createTextNode(this.original));
 this.editing = false;
 this.original = null;
 this.editcell = null;
 if(e)e.stop();

 }
 [etc...]
 }
 -

 I have the following problem: the 'this' variable is overwritten by
 the EditGrid function every time one of its methods is called.
 Example: editCell is called on onclick on a tablecell, it thereby sets
 this.editcell to the target cell, and this.editing to true. But when
 the handleKey method is called by a onkeydown, this.editing is set to
 false, and this.editcell to null, like the values they had initially.

 What am I doing wrong?

There was a bug in connect that interfered with bind(). You can either
upgrade to the latest svn trunk, or change this:
connect(window,'onkeydown',this.handleKey);

to this:
connect(window,'onkeydown',this, 'handleKey');

-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 DOM manipulation performance?

2007-06-18 Thread Bob Ippolito

On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Hi

 I've been reading a bit about some optimised DOM manipulation
 libraries developed for the yui-ext, jQuery and Dojo toolkits:

 http://www.jackslocum.com/blog/2007/01/11/domquery-css-selector-basic-xpath-implementation-with-benchmarks/
 http://jquery.com/blog/2007/01/11/selector-speeds/
 http://dojotoolkit.org/node/336

 This discussion occurred in January/February of this year, and the
 upshot was that these toolkits were drastically improving their DOM
 manipulation performances. MochiKit gets mentioned in the benchmark
 done on domQuery (the yui-ext engine), and performs horribly (10 to
 100 times slower than domQuery, if the test is to be believed).

 My question is, are these benchmarks accurate, and if so, what has
 been done since to improve MochiKit's DOM performance?

This is a very particular kind of DOM query (CSS selector emulation)
that is currently experimental in MochiKit SVN trunk. It has not yet
been optimized, but it's also not currently used internally by
MochiKit.

-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: Different search result for different browser

2007-06-17 Thread Bob Ippolito

On 6/17/07, tired [EMAIL PROTECTED] wrote:

 When I try to search on JSON file with same search key in different
 browser with sortable table, the result is different. IE6 shows only
 those results (row) where search character(s) arrive at the very
 beginning (like first letter(s) of sentence) of the  data. Why not
 getting the result like FireFox (looks appropriate).


You're probably going to need to show some code. Your description
doesn't really have enough information to determine why you're seeing
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: How prevent mochikit from html entity decode of sortable data?

2007-06-16 Thread Bob Ippolito

On 6/15/07, tired [EMAIL PROTECTED] wrote:

 I have used the 'mochikit sortable' table to sort data (loading a json
 file through ajax). In that table one of columns has linked data which
 htlml entity decoded by mochikit, so it show raw html instead link.
 For example, I supplied the data like

 a href=drink-details.php?drink_id=153Red Wine Glass: Use for red
 or white wine (if you don't have a white wine glass), or water./a

 But mochikit show it like,

 lt;a href=drink-details.php?drink_id=153gt;Red Wine Glass: Use for
 red or white wine (if you don't have a white wine glass), or
 water.lt;/agt;

 That is it decode the '' and '' to 'lt' and 'gt'.

 Anybody help me how to prevent this type decoding?

It's not decoding anything, the DOM works with nodes not markup. Text
turns into text nodes.

In order to turn literal HTML into a DOM node you'll have to use
something like this:

function htmlDiv(htmlText) {
var s = DIV();
s.innerHTML = htmlText;
return s;
}

-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: createDom option example please

2007-06-15 Thread Bob Ippolito

On 6/15/07, hotani [EMAIL PROTECTED] wrote:

 Ok. Like I say, this is not very clear to me right now, and I'm trying
 to create an option list for a drop-down.

 Let me put up my shot-in-the-dark example, then maybe someone can
 correct me:

 // add a single value/text option to drop-down:
 OPTION(null, {'value': '123', 'text': 'some text'});

 Trying to create this: option value=123some text/option
 and a bunch more if everything goes well

The first argument is attributes, additional arguments are contents.

OPTION({'value': '123'}, some text);

-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.Async, synchronousness, and testing

2007-06-11 Thread Bob Ippolito

On 6/11/07, GK [EMAIL PROTECTED] wrote:

 I've been Googling around looking for tools to help with testing of
 asynchronous code using mochikit's Deferred's.  The only thing I found
 so far was this post from over a year ago, to which there was no
 response.
   http://groups.google.com/group/mochikit/msg/53af9c5dece6e576

 What I'm looking for is something akin to the 'twisted.trial.unittest'
 package that extends a synchronous unit test framework to handle
 deferred results.  Ideally, I'd like to be able to mix synchronous and
 deferred tests in a single suite.

 I think I can see a way to achieve this, effectively absorbing all the
 tests into a reactor monad (wrapping any synchronous values in
 mochikit.async.succeed) and supplying a testrunner that collects the
 results and analyzes them when all deferreds have fired.  But before I
 spend too much effort trying to figure the details of doing this, I'd
 be interested to hear if anyone has already done anything similar for
 mochikit.


How about looking at how MochiKit.Async's tests work?

-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: Arabic Spam

2007-06-10 Thread Bob Ippolito

On 6/10/07, Arnar Birgisson [EMAIL PROTECTED] wrote:
 On 6/9/07, Bob Ippolito [EMAIL PROTECTED] wrote:
  I've just changed the moderation settings to moderate all messages
  from new users. I'm not sure how much that's going to help though.

 I'll volunteer as a moderator if you like. I'm in timezone GMT+0


Excellent. You should have permission to moderate now.

-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: getNodeAttribute Doesn't Work In An OnFocus Handler

2007-05-22 Thread Bob Ippolito

On 5/22/07, MikeC [EMAIL PROTECTED] wrote:

 It seems that I am being forced to not use getNodeAttribute in one
 instance. I created a small example (see below) of where it seems to
 fail. My little example contains two text boxes. You enter some text
 in the first one and the onfocus handler for the second text box will
 show you (via an alert function) the content of the first box. The
 problem is that it doesn't work using MochiKit's getNodeAttribute. But
 it does work using the less desirable construct...

 text1Val = document.TheForm.text1.value;

 Thanks for any explanation of why this is the case.

I'm not entirely sure why it doesn't work.. but it's probably because
you're going through the ancient form API rather than the DOM API.

I don't see any real reason to prefer getNodeAttribute for value in
this case. Do you like it because it's slower and less direct?  ;)

-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: IE6 problem with OPTION

2007-05-17 Thread Bob Ippolito

On 5/17/07, Paul [EMAIL PROTECTED] wrote:

 So I'm trying to create a page that will populate a collection of
 SELECT's using some AJAX requests. The AJAX part goes fine and I get
 data back from the server, it's just when I'm trying to create new
 options that I'm running into problems with IE6

 For example:

 dataTarget = getElement('id_mySel') //This is just a generic SELECT
 dataTarget.options[dataTarget.options.length] = OPTION({'value' : 1},
 'Some text');

 On Firefox that code works perfectly fine, but with IE6 it fails with
 Object doesn't support property or method
 replacing OPTION with new Option('Some text', 1) works perfectly
 fine. Bug (in IE)?

 This happens with Mochikit checked out from SVN @ rev 1292
 IE 6.0.2900.2180.xpsp_sp2_gdr.070227-2254
 WinXP Pro SP2

Have you tried using DOM functions instead? Something like this:
appendChildNodes(id_mySel, OPTION({value: 1}, some text));

-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: Does Mochikit accept patches for Format.LOCALE ?

2007-05-16 Thread Bob Ippolito

On 5/16/07, Roger Demetrescu [EMAIL PROTECTED] wrote:

 If it is possible, could you guys add this brazilian-portuguese locale
 to MochiKit.Format.LOCALE ?



 ...
 pt_BR: {separator: ., decimal: ,, percent: %},
 ...

Ok, it's in r1292.

-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: evalScripts:true equivalent in Mochikit?

2007-05-15 Thread Bob Ippolito

On 5/15/07, Spiderr [EMAIL PROTECTED] wrote:

 Thanks Kevin,

 This works great! This seems a very fundamental thing to want to do...
 am I missing something? Why isn't this in Async.js or similar?


It's not really that common. Most people using MochiKit are loading
data, not code, and if they are loading code then it's usually not
mixed with other stuff.

-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: Bug in queryString?

2007-05-03 Thread Bob Ippolito

On 5/3/07, Arnar Birgisson [EMAIL PROTECTED] wrote:

 Hi all,

 The current svn version of queryString gives me something unexpected on this

 queryString({nonni:null, x:3})

 It gives me a silent error and no result. The docs say attributes with
 null values or undefined will be skipped, so I was expecting x=3
 here.

 Further investigation shows that the line that fails is Base.js:1115:

 typeof(v.length) == number

 I assume this is failing because null has no .length property.


 Am I doing something wrong here? I find it unlikely that no-one has
 bumped into this before since this affects everything that uses
 queryString, including loadJSONDoc.

 If this is clearly a bug, I'd only be happy to commit a fix.


Sounds like a bug. Please commit a test that fails, then commit a fix :)

-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: Fix for CVE-2007-2381

2007-05-01 Thread Bob Ippolito

On 5/1/07, Konstantin Ryabitsev [EMAIL PROTECTED] wrote:

 Hello:

 Will there be a fix for http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-2381
 in the 1.3.1 branch?


Nope. It's not a real security issue, not with MochiKit anyway. The
recommended fix would mean supporting some junk that's not JSON
anymore. I've already caved and put said support on the trunk just so
people would shut up about the issue, but I'm certainly not going to
make a maintenance release to fix this non-issue.

Ensuring that your server only sends JSON when properly authenticated,
or otherwise sending only non-exploitable JSON (e.g. JSON with an
object envelope) is the only solution to this problem.

Only a very small subset of JSON, specifically [array, envelope, json]
is susceptible to this data leakage attack. Don't send that stuff on
the server-side, and there is no problem. Most people don't send array
envelope JSON anyhow. Either way, totally irrelevant to the
client-side. It's like saying that we should fix browsers so that they
can't be used to mount a SQL injection attack on a poorly written
service.

-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
-~--~~~~--~~--~--~---



  1   2   3   4   5   6   >