[mochikit] Re: Removal of Dojo and JSAN support
Good riddance... -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Per Cederberg Sent: Tuesday, November 18, 2008 2:57 PM To: MochiKit Subject: [mochikit] Removal of Dojo and JSAN support Just wondering -- is there anyone out there using MochiKit as a JSAN or Dojo package? Bob and I recently discussed removing the support code from MochiKit, since it seems kind of out-dated. Also, the Dojo support has been pretty broken before without anybody noticing for a long time. Any protests? Otherwise I'll just go ahead and clean it up in 1.5. Cheers, /Per No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.6/1797 - Release Date: 11/18/2008 11:23 AM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit 1.4 released
Congrats and thanks to everyone involved for all of the hard work that goes into maintaining this stable toolkit! Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Per Cederberg Sent: Tuesday, October 21, 2008 4:32 AM To: MochiKit Subject: [mochikit] MochiKit 1.4 released MochiKit 1.4 has now been released and is available on the web site: http://mochikit.com/download.html The full change history from version 1.3.1 is rather lengthy, but you can find it on our web site: http://mochikit.com/doc/html/MochiKit/index.html#version-history As far as I know, there should be no backwards-incompatible API changes between 1.3.1 and 1.4. If you happen to find one, please let us know through this mailing list so that we can update the docs and/or fix the issues. Finally, many thanks to everyone who contributed code, documentation, bug reports, ideas and everything else during this long development cycle. Looking forward to hear from you all during the 1.5 development. Cheers, /Per No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.2/1737 - Release Date: 10/21/2008 9:10 AM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.DOM.isChildNode and isParent
Who is Noone? :P Personally, I agree that it seems pointless to have isParent around when isChild will do the same thing. I don't even think the alias is needed, if someone wanted the semantics that would provide, let them alias it themselves, I say. There is my opinion, for what little it is worth. Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Per Cederberg Sent: Friday, October 17, 2008 2:29 PM To: MochiKit Subject: [mochikit] Re: MochiKit.DOM.isChildNode and isParent Noone has opinions on this? Cheers, /Per On Wed, Oct 8, 2008 at 3:51 PM, Per Cederberg [EMAIL PROTECTED] wrote: The two functions MochiKit.DOM.isChildNode and isParent have both been added in version 1.4 of MochiKit (not yet stable). But they are virtually identical (except for a few bugs I'm in fixing right now). The only difference, according to the API docs, as far as I can tell is: isChildNode(node, node) -- true isParent(node, node) -- false Is it not pointless to keep both functions around? Since isChildNode() is more tested (and probably more used), I'd suggest removing isParent() from the API before the 1.4 release. Possibly, in order to simplify the transition, we could just alias isParent to isChildNode (and remove the API doc specification so that noone will use it from now on). Opinions? Cheers, /Per PS. I just discovered that Google Groups silently dropped all my emails that used another sender address, so I'm currently resending all my recent postings. Hence the sudden email bombing... No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1730 - Release Date: 10/17/2008 8:07 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: Why doesn't removeElement use the DOM Coercion rules?
On Friday, October 10, 2008 at 11:33PM Bob Ippolito wrote: If you'd like to fix it then I don't see why the patch would be rejected. Sounds good, I will do just that. Thanks, Jason --~--~-~--~~~---~--~~ 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?
On Saturday, October 11, 2008 at 2:50AM Per Cederberg wrote: On Thu, Oct 9, 2008 at 6:50 PM, Jason Bunting [EMAIL PROTECTED] 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. There is no specification on this, it is just kind of what you'd expect. Why would otherwise the parent node be an input parameter? If the result is constant, no parameter in the world can change that. I could just as easily ask why the result of the call would be coerced to a DOM element - and I can think of situations where knowing about the intended parent node would be useful to a 'widget' when its __dom__ or dom function is called with it. Consider, for example, that a widget might want to use the dimensions of the parent node for setting its behavior - when __dom__ is called, I can gather information about the passed-in parent node and update my widget's size or behavior before passing back the thing that will be coerced for placement in the DOM. 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. I wasn't thinking about widgets, but rather situations were you'd added a dom() method to various other objects. For convenience. I won't fault you for your particular view of how one might use certain facilities of MochiKit if you don't fault me for mine. :) 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. I shouldn't start an OO discussion here, but in my opinion the fields in an object are all public unless names are prefixed with an _. In the widgets I develop, the private fields are not accessible because of closures. Doesn't make sense to me to call something private when it isn't really private (or when it is only considered private because of a naming convention). 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 ... Ehm... The proposed MochiKit.Widget isn't an entire widget framework. I just pointed at it for example, not to force you to change your code or your ways. It is far more of a widget framework than what I currently use, so to me it is an entire widget framework. :) Besides, it is meant to do just that, isn't it? I think the word entire is rather subjective. And I realize you were not trying to force me into anything. I don't oppose changing there MochiKit.DOM functions, I'm just of the opinion that it isn't much of a problem. And if it is, I'd suggest that we check typeof(o.dom) == object or something. So that we know for sure that what is being removed is an existing DOM node, not something that was created by our call to o.dom()... Also, doing that would increase our compability with Dojo et al. I will create a patch and it can go up for discussion - I already modified removeElement() a week ago to test things out and all I did was simply call coerceToDom() within
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post
[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
--~--~-~--~~~---~--~~
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] Why doesn't removeElement use the DOM Coercion rules?
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
--~--~-~--~~~---~--~~
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
Arnar Birgisson wrote: To be clear, I'm basically asking the mailing list: Would you be OK with it if the following selectors would stop working? a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class Sounds good to me - would it be too hard to hook into Sizzle and add these ourselves so that the tests pass? I don't know squat about the current code and what is involved in doing this; would it be much work? Jason --~--~-~--~~~---~--~~ 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 can I refresh a particular div in a document
Ranjan, I have the JSON objects(got from the XMLHttpRequest) and I want to refresh a particular div of a document with the JSON data (without refreshing the whole page). Needing help. A bit more information (ideally, sample code) would be useful in trying to offer assistance to you. Perhaps you can provide us more details? 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: MochiKit Extensions
I haven't had time to respond to Amit's post, but I thought I would take the time now to indirectly respond via Per's comments... Per Cederberg said: snip what would be interesting is a jQuery compability module, mapping jQuery calls into MochiKit ones. At least so that some jQuery plug-ins would be usable with MochiKit. Perhaps that might be a worthwhile idea...very interesting...I wonder how much work that would be. Anyone have an idea? What are the use cases for the proposed MochiKit.Remote module? What would the API look like? Why isn't the Async module sufficient? (What is missing in your opinion?) I was wondering the same thing... 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: help with createDOM
I tried your code with both the current version of MochiKit, 1.3.1, and
the latest packed version from the repository.
For both of those, your code worked just fine in FireFox 3.0.1 and IE 7 on
Windows XP Pro.
Not sure what your problem is, so maybe someone else has an idea. Which
browser is this failing in? If you want additional examples, even though
your example seems to work just fine for me, there are a few on the
documentation page:
http://www.mochikit.com/doc/html/MochiKit/DOM.html
Jason Bunting
-Original Message-
From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Monday, September 01, 2008 11:21 AM
To: MochiKit
Subject: [mochikit] help with createDOM
Hello,
I'm new to mochikit, i'm trying to use it to create HTML fragments
with DOM api (i'm using mochikit from SVN).
The following code is working :
//
var new_node = H1('hello');
var target = document.getElementById('title');
swapDOM(target, new_node);
//
hello is correctly displayed.
But this code NOT :
//
var new_node = DIV({'id':'title'}, H1('hello'));
var target = document.getElementById('title');
swapDOM(target, new_node);
//
[object HTMLHeadingElement] is displayed in place of hello.
Do you have any working example of DOM usage please ?
Thx.
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.14/1645 - Release Date: 9/1/2008
7:19 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: Random Ideas for Mochikit.DOM
But my personal focus right now is on fixing and investigating all outstanding issues before a 1.4 release (moving very slowly, I admit). What's left to do before we hit that? I would love to help, if I am able to work it in, but am not current on what the outstanding issues are... I've got a MochiKit-styled widget library that I intend to contribute in due time and there is a bunch of other stuff floating around. Yeah, I not only have some MochiKit-based widgets/controls/whatever in various states of development, but would love to see us gather everything similar that exists out there and make it available in one place, create and improve existing demo code, etc. Maybe those of us interested in doing this should come up with an actual plan instead of just mentioning it on this list every 3 months. :) We should formalize the end goal and how we plan on accomplishing it. Where would we host this widget library? Would Bob be willing to host that kind of stuff? Does it belong with the rest of the MochiKit code in the same repository? I know we once loosely discussed this, but maybe we should once again just to get some momentum going, I don't know. All I do know is that I love using this library and have a vested interest in keeping it around and building support around it (makes it an easier sell to clients that hear about nothing but jQuery, Dojo, YUI and prototype/scriptaculous). Hope everyone has a nice weekend! Jason Bunting _ Get thousands of games on your PC, your mobile phone, and the web with Windows®. http://clk.atdmt.com/MRT/go/108588800/direct/01/ --~--~-~--~~~---~--~~ 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
of that community, and here the culture is if it ain't broke don't fix it. That sort of culture is great for stability, but it's not very conducive to improvement. I think when you say improvement in this last statement you mean changes I want, which I also want you to implement, because improvements do seem welcome here to me. And by the way, if it ain't broke don't fix it is a wonderful policy, as far as I am concerned. I want a framework that takes advantage of all the latest developments in the world of JS. You do know that the last official changes to the ECMA spec were made in 1999, right? Until another is made and there is wide-spread adoption, I don't see there being any developments in the world of JS in the way that you seem to imply. And again, if there are useful things that somehow come about, as earlier alluded to in the comments about the XmlHttpRequest abstraction, I am certain the few of us that use MochiKit will make sure such features are implemented. That framework isn't Mochikit. Well, hasta la vista then - hope you enjoy using jQuery; may it be everything you, and the thousands of other people using it, want it to be. Who knows, maybe someday I will be using it as well - only it will not be because I feel MochiKit has grown stagnant or because my ideas aren't implemented; rather, it will be because of a conscious choice based on an actual need. 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: Random Ideas for Mochikit.DOM
Jeremy, Mochikit is VERY resistant to change, and if you try to suggest changes people will basically tell you why don't you go use that other library if you like their features so much. I think the fact that MochiKit is resistant to change is a Good Thing - we can't make changes for every Tom, Dick and Harry that think it needs some feature. As far as I can tell, 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. As a side note, that line of thinking (coupled with the lack of any real development) has convinced me that Mochikit is far too stagnant for my company's business needs. As a result, I'm currently in the process of researching how to migrate us to jQuery. Is the lack of development necessarily indicative of a problem? When fruit matures on a tree, it stops development and is picked and eaten. I think MochiKit is mature and I have absolutely no problems with it, what things is it missing? I rarely find things I need that MochiKit doesn't already provide (unless, of course, you are looking for widgets and such). So, I don't mean to be yet another voice saying give up and go use jQuery, but in my experience that path will be MUCH more rewarding than trying to convince the Mochikit maintainers to change ... well, anything. Is this because they wouldn't add a few aliases for you? If so, that's a poor reason to leave. I am really curious as to what you see missing - granted, a better community of users would be nice, as far as developing reusable widgets and such (I develop niche stuff and have to roll my own regardless), but other than that, I don't see the library itself as missing anything. As your last goodwill effort, provide some useful feedback. 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: Random Ideas for Mochikit.DOM
Why wouldn't you just use $$(.someClass) rather than getElementsByTagAndClassName(null, someClass)? Just curious... Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of machineghost Sent: Tuesday, August 19, 2008 10:29 AM To: MochiKit Subject: [mochikit] Random Ideas for Mochikit.DOM Hey All, I use a couple of alias functions in every project where I use the DOM library: /* Shorten getElementsByTagAndClassName, because we know that we're getting elements (nothing else has a tag/class) and we know we're doing it by the name of the class or tag, because there is no other way to identify a tag or class (pretty much all they are is a name). */ var getByTagAndClass = getElementsByTagAndClassName; /* I use getElementsByTagAndClassName(null, someClass) all the time, and it seemed silly to have to repeat a longer function name and a null, every time. */ var getByClass = partial(getByTagAndClass, null); Any chance of either of these making it in to Mochikit proper? BTW, even if the first one was implemented, I'd still think we should keep it as an alias (rather than changing getElementsByTagAndClassName) to avoid breaking old code. Also, if the maintainers' really like long function names for some odd reason, the second one could just as easily be implemented as getElementsByClassName and still provide the same usefulness. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 8/19/2008 6:04 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: Random Ideas for Mochikit.DOM
Personally, in both my client-side as well as server-side code, I prefer long names that leave little room for doubt about what a variable or method/function is meant to be or do. My server-side code is compiled, so long names matter little, and I used the Dojo ShrinkSafe tool to bring down the size of my JavaScript, so I get the same benefit - long names for better reading and writing of code, and when it is time for deployment, short names (with the exception of those functions in MochiKit, which isn't a big deal to me). I think using aliases is nice, but your particular pattern of using MochiKit may not be the same as others, so I don't see a reason to change things. I rarely use the functions you mention, so their longs names are no problem for me. Just my opinion, for what little it is worth. Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of machineghost Sent: Tuesday, August 19, 2008 10:38 AM To: MochiKit Subject: [mochikit] Re: Random Ideas for Mochikit.DOM Just noticed a few more aliases I had somewhere else (which are along the exact same lines): var firstByTagAndClass = getFirstElementByTagAndClassName; var addClass = addElementClass; var removeClass = removeElementClass; I guess what I'm asking for in this thread is Am I the only one who thinks that including 'name' and 'element' in all these functions' names makes them needlessly long? If not, how about we make some aliases? Well, except with getByClass/getElementsByClassName; that I think would be useful even if everyone DOES like 'name' and 'element'. Jeremy On Aug 19, 9:28 am, machineghost [EMAIL PROTECTED] wrote: Hey All, I use a couple of alias functions in every project where I use the DOM library: /* Shorten getElementsByTagAndClassName, because we know that we're getting elements (nothing else has a tag/class) and we know we're doing it by the name of the class or tag, because there is no other way to identify a tag or class (pretty much all they are is a name). */ var getByTagAndClass = getElementsByTagAndClassName; /* I use getElementsByTagAndClassName(null, someClass) all the time, and it seemed silly to have to repeat a longer function name and a null, every time. */ var getByClass = partial(getByTagAndClass, null); Any chance of either of these making it in to Mochikit proper? BTW, even if the first one was implemented, I'd still think we should keep it as an alias (rather than changing getElementsByTagAndClassName) to avoid breaking old code. Also, if the maintainers' really like long function names for some odd reason, the second one could just as easily be implemented as getElementsByClassName and still provide the same usefulness. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 8/19/2008 6:04 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] Problems using partial toggleElementClass as an event handler...
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?
Thanks,
Jason Bunting
_
Making the world a better place one message at a time.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_BetterPlace
--~--~-~--~~~---~--~~
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: Combine scripts to single file
Also have a look at scripts/pack.py - you can use it to pack your own, selecting only those modules you care to have (being mindful, of course, of dependencies between them). FYI: In order to use pack.py, you will need a python interpreter and apparently, someone correct me if I am wrong, Java. Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Per Cederberg Sent: Thursday, June 12, 2008 7:33 AM To: MochiKit Subject: [mochikit] Re: Combine scripts to single file packed/MochiKit/MochiKit.js Cheers, /Per On Thu, Jun 12, 2008 at 2:31 PM, Ragnar Rova [EMAIL PROTECTED] wrote: Is there a recommended way of combining MochiKit stable to a single .js file to reduce the number of http requests? No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.2.0/1497 - Release Date: 6/11/2008 8:32 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: other widget toolboxes most compatbile with mochikit?
I would be very interested in participating in an effort to build up a library of code that uses MochiKit if someone wants to get that going; I ported Cody Lindley's jQuery-based ThickBox over to MK quite a while back and think it would be nice to have similar widgets around for MK to help me sell the idea of using MK to those around me. MochiKit port of ThickBox 2.1: http://www.sapientdevelopment.com/dotnetnuke/downloads/Mochikit/MochiKitThic kBox.zip Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Gardner Sent: Friday, February 15, 2008 3:02 PM To: MochiKit Subject: [mochikit] Re: other widget toolboxes most compatbile with mochikit? If you are willing to share your code, I am sure others would be as well. It would be nice to have a calendar widget and other common things, but I don't know that there is a good solution out there as far as a framework or whatnot. Having developed a largish application in MochiKit (http://www.amazon.com/gp/gss/browse) I didn't come away thinking that adding a lot more code for a framework was the really right way to do things. (It feels like square peg, round hole.) I'd rather stay as close as I reasonably can to DOM and such, using MochiKit to smooth a few rough edges. On Feb 15, 12:57 pm, Chris Lee-Messer [EMAIL PROTECTED] wrote: First, I want to thank Bob and the rest of the mochikit team for this great library. As a javascript neophyte, I chose Mochikit because it seemed to fit my way of thinking. I use python a great deal and mochikit with it's good documentation and clarity of organization made javascript more rational to me. Thanks to Mochikit, I was able to build an in-house ajax-type web applicaton from scratch and bring it live within a few weeks. Now I am looking to add more features and I would like to avoid spending time writing javascript widgets if it's not necessary. There are now quite a few popular widget libraries and I have looked at several of them (yui, dojo, jquery, etc.). Quite a few people have put together comparisons and reviews and I am not looking to repeat that discussion here. The question for me is how compatible the mindset of a library is with what I've done before. Some of the pythonista's like to say Python fits my brain. Mochikit fits for me and ideally, any library that I add would do the same. I'm interested in finding out from mochikit users if they think that ne of the javascript widget libraries best fits the mochikit way of doing things. Alternatively, having a place--say on google code--with mochikit- based widgets would allow the community to gradually build up a set of mochikit-based widgets. Many thanks. -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: other widget toolboxes most compatbile with mochikit?
It's great to see the responses. I'd like to split the thread in two: 1. Among the existing javascript widget libraries, is there one that is most compatible with mochikit's approach? This is not really an answer to your question, more an expression of my feelings on other libraries in general: Personally, and I know this may sound heretical to some, I would rather not use another library with MochiKit; when I am in complete control of things, I prefer to do everything with just MochiKit - this may be because I am working on applications (not websites, per se) that have a need for functionality that isn't common enough to find in someone's widget - it is too custom for that. Not only that, but I really, really enjoy writing things myself simply for the exercise and such - not because I suffer from NIH per se, simply because I enjoy writing code. 2. It sounds like there is interest in creating a repository for mochikit widgets and/or code snippets. Do people have a preference for where it should be hosted? At mochikit.com? On sourceforge, savannah, googlecode? I vote for keeping it on the MochiKit website - a while back Bob said that he would give control of things over to the right person, but no one stepped up, AFAIK. Of course we are not really talking about taking over the MochiKit code base, so perhaps this is relevant. Regardless of what I am rambling about, I think it would be nice to keep things on the MochiKit website, obviously making this not a normal part of the MochiKit library. We could start populating the project with Jason Bunting's thick box. A google search also showed a project on sourceforge with other intreface components. (I seem to have missplaced the URL). That port is a bit old - ThickBox is up to version 3.1 now; I will try to update it in the next week. There are a few MochiKit-based add-on libraries floating around: http://gr.ayre.st/~grayrest/animator/animator.html This is one I would love to see finished - supposedly there is work yet to be done on it, I wonder what Karl is up to these days and if he would like to participate or otherwise assist in such an effort as the one we are proposing. http://svgkit.sourceforge.net/ I know nothing much about this one. http://ui4w.sourceforge.net/ This one looks to be dead as well, but might offer some scraps worth using - perhaps we can talk to the original authors and ask if they don't mind us using some of their stuff as well. Others?! These are the only ones I know of and have ever heard of - while there is nothing wrong with people developing their own MochiKit-based stuff in isolation, it sure would be nice to make a concerted effort at developing a nice set of widgets/controls/foo/etc. for MochiKit. I still don't know why MochiKit isn't one of the more popular libraries - maybe I am biased because I have been using it for so long?! I went to a jQuery class put on by some coworkers and wasn't that impressed; either jQuery isn't that great or the class wasn't designed to highlight its strengths. 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: Walk child nodes of an element
To what end do you want to get at the text? If you simply want to grab it,
use scrapeText()...
Jason
-Original Message-
From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of JS
Sent: Monday, December 10, 2007 8:53 AM
To: MochiKit
Subject: [mochikit] Walk child nodes of an element
Hi:
I'm quite new to MochiKit and javascript in general. For some reason,
I can't figure out how to walk the child nodes of an element. I'm
using version 1.3.1 of MochiKit with TurboGears.
I have table cell and am trying to drill down into the cell to get at
the text that is being displayed in it. The cell could have some SPAN
elements and then either text or a link.
In effect, I would like to do the following:
...
while cell.hasChildren() {
cell = cell.firstChild;
}
I realize that each cell could have multiple children, but in my
specific case, it won't.
I'd really appreciate any pointers to examples or good documentation.
Thanks
-Jim
--~--~-~--~~~---~--~~
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
On 10/16/07, troels knak-nielsen [EMAIL PROTECTED] wrote: On 10/16/07, Daniel Fetchinson [EMAIL PROTECTED] wrote: Five months ago someone posted a list of blocking bugs: On May 15, 9:57 pm, sayrer [EMAIL PROTECTED] wrote: http://trac.mochikit.com/ticket/113 http://trac.mochikit.com/ticket/226 http://trac.mochikit.com/ticket/228 http://trac.mochikit.com/ticket/241 http://trac.mochikit.com/ticket/248 All of these have been fixed but the last, which has been switched to priority:low. For those of us not running from svn, is a 1.4 release on the horizon? (Remembering that it was almost done a year ago.) Or has everyone switched to jquery? :) -Jonathan What's wrong with running from svn? For me it was very stable so far. Following on the recent thread about activity, it would probably be good publicity to throw out an official milestone. It's bordering on arrogant to assume that people who want to use MochiKit must be geeky enough to use SVN. Most javascripters aren't. I love how often this comes up and how often Bob explains what his interests are concerning this... Notwithstanding that, I wish someone would take care of officially releasing a 1.4 version. --~--~-~--~~~---~--~~ 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: IE 7 Issues
I believe this is the fix (though I reserve the right to be incorrect!): Tools - Internet Options. On the General tab (first tab), click on Settings in the Browsing history section. Select Every time I visit the webpage. Let me know if that fixes the problem for you. Of course, this solution is very specific to the client hitting your page. If you are creating a site for use by people that may not have that setting setup that way, you will want to stick with the timestamp hack. Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Dave Marsh Sent: Wednesday, October 10, 2007 1:21 PM To: MochiKit Subject: [mochikit] Re: IE 7 Issues You are correct, adding a timestamp worked. Do you know if there is a way to shut it off? On Oct 10, 2:02 pm, Kevin Damm [EMAIL PROTECTED] wrote: It's probably an issue with IE7 aggressively caching the request. Try adding a unique string (e.g. datetime and a random number) to the end of your request as part of the query string so that IE views it as a unique page. So, an example,http://mysite.com/ajax-process.php?var=value would becomehttp://mysite.com/ajax-process.php?var=valuet=1192039355- 1325 See other posts in this list for similar problems. - Kevin On 10/10/07, Dave Marsh [EMAIL PROTECTED] wrote: Hello, I'm using mochikit 1.3.1 in a web application (it's being included through turbogears if that makes a difference). Everything works fine in FF, but in IE 7 I'm having a strange problem. When I visit the page for the first time, the very first ajax request is executed without a problem. All subsequent requests, however, are not even sent to the server (I added print statements to my server side code to verify whether or not it was actually being hit). It seems to just recycle the previous response. Any help would be appreciated. --~--~-~--~~~---~--~~ 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: Callbacks work when Firebug is turned on but not when off or not
Without your providing the code so that it can be duplicated, I am not sure how much help you are going to receive Jason Bunting From: John Lorance [EMAIL PROTECTED] To: MochiKit mochikit@googlegroups.com Subject: [mochikit] Callbacks work when Firebug is turned on but not when off or not present. Date: Fri, 14 Sep 2007 11:30:55 -0700 Here's a strange one.. I have my application working perfectly using Firefox 2.x on Mac or Windows.. but then I noticed for users with Firefox w/o Firebug installed or when disabled, my callbacks don't get triggered. I can verify that my Ajax calls to the server (sendXMLHttpRequest(request, queryString(params)).addCallback(mySampleCallBackFunction)) get sent; but the response never seems to trigger a callback... I find this problematic in IE 6 as well... Is there something obvious I am missing here? Cheers, John _ A place for moms to take a break! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us --~--~-~--~~~---~--~~ 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: Sortable List - Dropped Element ID
The documentation on the sortables stuff sucks - but then, it isn't really
considered a core piece of MK so I guess there is little motivation to fix
the problem.
Here is a concise example of the technique I am using, for better or worse:
var m_CurrentSortable = null;
function CreateSortables() {
MochiKit.Sortable.create(elementForSortableList, {onUpdate: function() {
log(Here's the id: , m_CurrentSortable.element.id);
}});
}
connect(Draggables, start, function (draggable) {
m_CurrentSortable = draggable;
});
Supposedly you can attach to an ondrop event, but I can't get that to work
right. According to the sortables documentation page, other options are
passed to the Draggables and Droppables objects created. Refer to
MochiKit.DragAndDrop for more information.
Hope that helps,
Jason Bunting
-Original Message-
From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Urbanite
Sent: Tuesday, September 04, 2007 8:56 PM
To: MochiKit
Subject: [mochikit] Sortable List - Dropped Element ID
I am considering trying MochiKit for use in a sortable list scenario
that involves several lists on a single page. Idea being that when an
element is dropped from one list to another, the id of the dropped
element becomes available for use in an Ajax callback to update a
database.
Problem I am running into is that in reading the docs on the
MochiKit.com site, I have found mention of an Observer, but no
direct API reference on how to use it. Can one of you offer a bit of
help on the observer thing?
Core question is how to get the id of a dropped list member.
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.5/989 - Release Date: 9/4/2007
5:54 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.5/989 - Release Date: 9/4/2007
5:54 PM
--~--~-~--~~~---~--~~
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: Form Validation
Lee Connell asked: Are there form validation helpers in mochikit? No and yes - there are not any in the sense you are probably thinking, but by virtue of the fact that MochiKit makes JavaScript suck less, there are. Hope that makes sense. Look through the relatively complete documentation and you will see what is provided; MochiKit has very little in its API that is as task-specific as form validation helpers, instead providing generic helps. Jason Bunting No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 8/19/2007 7:27 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] OT: Oliver Steele's Functional JS Library
Is anyone using Oliver Steele's functional JavaScript library along with MK?
It has the basic functional programming constructs like map, reduce, etc.
but rather than pass in function pointers (which you can do as well), you
can specify 'string lambdas' that embody what it is you are trying to do;
for example:
map(function(x) { return x+1 }, [1,2,3]);
can be written:
map('x - x+1', [1,2,3]);
or more succinctly:
map('x+1', [1,2,3]);
There is much more to it than this quick and simple example; he wrote a blog
entry about it here:
HYPERLINK
http://osteele.com/archives/2007/07/functional-javascripthttp://osteeleco
m/archives/2007/07/functional-javascript
The project's page:
HYPERLINK
http://osteele.com/sources/javascript/functional/http://osteele.com/source
s/javascript/functional/
Just wondering if there is any ideas here that may be useful for use within
MK and whether anyone has already started using this library with MK. The
full source is 33K but I was able to get it down to 9K with an obfuscation
tool.
Jason Bunting
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007
2:55 PM
--~--~-~--~~~---~--~~
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: Functions called by addLoadEvent can't access the DOM
Well, if your function is called myFunction and you are *really* calling addLoadEvent like this: addLoadEvent(myFunction()); then your problem is simple: you need to call addLoadEvent like this: addLoadEvent(myFunction); Notice the difference? Jason Bunting _ From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Kieran O'Neill Sent: Tuesday, June 26, 2007 5:02 PM To: mochikit@googlegroups.com Subject: [mochikit] Functions called by addLoadEvent can't access the DOM I found a bit of a weird situation (bug)? with addLoadEvent. I have a function that I want to execute synchronously once the page has loaded, doing some fairly minor but important page changes. However, when I attach it using addLoadEvent(myFunction()), code within myFunction can't get to the DOM. (ie: Calls to both MochiKit DOM functions and to getElementById fail.) When I execute the same function from the html using body onLoad=myFunction() , it works fine and has access to the DOM. Anyway, for now simply calling the function using onLoad is a solution, although it would obviously be better, for future compatibility with other scripts, if I could rather use addLoadEvent. I am using MochiKit 1.3.1 and have tested this on Firefox HYPERLINK http://2.0.0.32.0.0.3 on Linux. I wasn't sure if this was a bug, or if there was something I just wasn't understanding about how addLoadEvent works, so I posted it here. Anyway, I hope this is useful. Regards, Kieran No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.9/871 - Release Date: 6/26/2007 4:16 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.9/871 - Release Date: 6/26/2007 4:16 PM --~--~-~--~~~---~--~~ 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: onUpdate doesn't work for Sortable?
Wow - either no one really knows how to help me or this list is even deader
than I thought.
Guess I will have to become an expert on the internals of MK to get this
figured out...
:)
-Original Message-
From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of JasonBunting
Sent: Friday, June 22, 2007 3:56 PM
To: MochiKit
Subject: [mochikit] onUpdate doesn't work for Sortable?
I have the following unordered list:
ul id=List
liFirst/li
liSecond/li
liThird/li
/ul
I have the following code:
connect(window, onload, function() {
MochiKit.Sortable.Sortable.create(List, {onChange:function(e)
{
alert(e.innerHTML);
}});
});
This works just fine - when I sort, this fires as expected. However,
it is the following that I am having problems with:
connect(window, onload, function() {
MochiKit.Sortable.Sortable.create(List, {onUpdate:function(e)
{
alert(e.innerHTML);
}});
});
So, nothing happens. I am going off of the documentation and using the
latest out of subversion. It looks as though the onUpdate signal is
just not firing.Am I right or do I need to do more to get this
working?
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.6/863 - Release Date: 6/23/2007
11:08 AM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.9.6/865 - Release Date: 6/24/2007
8:33 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: onUpdate doesn't work for Sortable?
Arnar - Thank you for taking time to address my issue, I really do appreciate it! Yes, the documentation isn't very clear on the requirement of having the id look a certain way - I suppose if you stare at it long enough it could be inferred from the docs, but for someone using it for the first time it seems a bit cryptic; once one has knowledge of how it works, the docs seem to more clearly allude to the need for it. Thanks again! Jason -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Arnar Birgisson Sent: Monday, June 25, 2007 8:31 AM To: Jason Bunting Cc: JasonBunting; MochiKit Subject: [mochikit] Re: onUpdate doesn't work for Sortable? Hi Jason, On 6/25/07, Jason Bunting [EMAIL PROTECTED] wrote: Wow - either no one really knows how to help me or this list is even deader than I thought. Sorry, I was hoping someone else would pick up on this since I've never used Sortable myself. I did some tests though and figured out how to use it. The thing is that you need to give your options some id-s to identify them. Their ids is what is used to detect their order, and if they have no ids, no change in order is detected. The format option to Sortable determines how the item value is retreived from the element id. This option is a regular expression whose first group is used as the id string. The default value searches the element id up to the first _ character and takes whatever follows as the value. To make your example work, you need to change the markus so: ul id=list li id=item_1First/li li id=item_2Second/li li id=item_3Third/li /ul If you then call MochiKit.Sortable.sequence(list) - you can see how the parts following the _ make up the object values, in this case it returns list[]=1list[]=2list[]=3. If you want some other way of extracting the value from the li id-s, you can pass a regexp to MochiKit.Sortable.create as the format option. I can agree that the docs are not very clear on this. hth, Arnar No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.6/865 - Release Date: 6/24/2007 8:33 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.6/865 - Release Date: 6/24/2007 8:33 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: parseQueryString bug?
Hello? Can anyone help me out here? -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Bunting Sent: Friday, January 05, 2007 3:18 PM To: mochikit@googlegroups.com Subject: [mochikit] parseQueryString bug? If the url of the page is: http://www.foo.com/bar.aspx?baz=blah#bottom And the code is: var args = parseQueryString(document.URL); var paramValue = args.baz; At this point paramValue is equal to blah#bottom instead of just blah as I would expect; the fragment identifier is included when present; is there another way to do this? Is my use of document.URL incorrect? Currently I am working around this with: parseQueryString(document.URL.split(#)[0]); Thanks, Jason Bunting _ Communicate instantly! Use your Hotmail address to sign into Windows Live Messenger now. http://get.live.com/messenger/overview -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007 11:11 AM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007 11:11 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] parseQueryString bug?
If the url of the page is: http://www.foo.com/bar.aspx?baz=blah#bottom And the code is: var args = parseQueryString(document.URL); var paramValue = args.baz; At this point paramValue is equal to blah#bottom instead of just blah as I would expect; the fragment identifier is included when present; is there another way to do this? Is my use of document.URL incorrect? Currently I am working around this with: parseQueryString(document.URL.split(#)[0]); Thanks, Jason Bunting _ Communicate instantly! Use your Hotmail address to sign into Windows Live Messenger now. http://get.live.com/messenger/overview --~--~-~--~~~---~--~~ 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: Color.fromBackground broken in IE 7?
That works, thanks! Jason From: Thomas Hervé [EMAIL PROTECTED] To: MochiKit mochikit@googlegroups.com Subject: [mochikit] Re: Color.fromBackground broken in IE 7? Date: Wed, 29 Nov 2006 03:08:17 -0800 I checked in a workaround in revision 1225. Can you verify it corrects your problem ? Thanks. -- Thomas _ Share your latest news with your friends with the Windows Live Spaces friends module. http://clk.atdmt.com/MSN/go/msnnkwsp007001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmk --~--~-~--~~~---~--~~ 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] connectOnce on wiki
On the wiki at http://trac.mochikit.com/wiki/connectOnce there is this
implementation for a function that mimics 'connect' except it disconnects
after the signal fires once (copied from wiki):
function connectOnce(src, signal, dst, func) {
var S = MochiKit.Signal
var d
if (typeof(func) == 'undefined') {
func = dst
} else {
func = MochiKit.Base.method(dst, func)
}
var wrapper = function() {
func.apply(this, arguments)
S.disconnect(d)
}
d = S.connect(src, signal, wrapper)
}
Just trying to figure out if this is an equivalent implementation (it seems
to work, but just want to double-check):
function connectOnce(src, signal, dest, func) {
var connectionId = connect(src, signal, dest, func);
connect(src, signal, function() {
disconnect(connectionId);
});
}
Thanks
_
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp007001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmk
--~--~-~--~~~---~--~~
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: MochiKitThickBox + IE (6.0 and 7.0)
-Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Godoy Sent: Thursday, November 16, 2006 12:03 PM Subject: [mochikit] MochiKitThickBox + IE (6.0 and 7.0) Anybody here using MochiKitThickBox? I'm having problems with IE 6 and IE 7 where it doesn't work. It works perfectly on Firefox, though... Anybody solved / saw this? If you are referring to my implementation, I would love to know what problems you are having, as I developed it against both IE and FF and had no problems. You might want to either point to a publicly-available page that illustrates your issues or include one with your question - your questions are too vague to do anything useful with unless you get specific and provide code. Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.14.6/535 - Release Date: 11/15/2006 3:47 PM --~--~-~--~~~---~--~~ 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 with IE
Jorge Godoy writes:
Jason Bunting [EMAIL PROTECTED] writes:
Jorge Godoy on Thursday, November 16, 2006 at 8:25 AM wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
var newTable = DIV({'id':'action-place'},FORM({},TABLE({'class':
'small-font','style':'margin-left:14em'},
TBODY(null,
map(row_display, rows);
swapDOM(action-place, newTable);
Remember that IE *requires* THEAD and TFOOT.
That is not correct; it simply requires TBODY (see
http://www.mochikit.com/doc/html/MochiKit/DOM.html#dom-gotchas)
When in doubt, Ask Bob ;-)
http://groups.google.com.vc/group/mochikit/tree/browse_frm/month/2005-
12/541f615fc0f4f14b?rnum=61_done=%2Fgroup%2Fmochikit%2Fbrowse_frm%2Fmonth
%2F2005-12%3F
See item 2 in the above thread.
You can also remove thead and tfoot from the example in the link you cited
and
see if it works. It won't.
Must just be an IE 6 thing then because I am currently building tables this
way *without* THEAD or TFOOT just fine in IE 7I am going to test it in
IE 6 real quick because now I am curious
Jason
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.14.6/535 - Release Date: 11/15/2006
3:47 PM
--~--~-~--~~~---~--~~
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 with IE
Jorge Godoy writes:
Jason Bunting [EMAIL PROTECTED] writes:
Jorge Godoy on Thursday, November 16, 2006 at 8:25 AM wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
var newTable = DIV({'id':'action-place'},FORM({},TABLE({'class':
'small-font','style':'margin-left:14em'},
TBODY(null,
map(row_display, rows);
swapDOM(action-place, newTable);
Remember that IE *requires* THEAD and TFOOT.
That is not correct; it simply requires TBODY (see
http://www.mochikit.com/doc/html/MochiKit/DOM.html#dom-gotchas)
When in doubt, Ask Bob ;-)
http://groups.google.com.vc/group/mochikit/tree/browse_frm/month/2005-
12/541f615fc0f4f14b?rnum=61_done=%2Fgroup%2Fmochikit%2Fbrowse_frm%2Fmonth
%2F2005-12%3F
See item 2 in the above thread.
You can also remove thead and tfoot from the example in the link you cited
and
see if it works. It won't.
Well, here ya go:
html
head
titleNo THEAD or TFOOT needed.../title
script type=text/javascript src=MochiKit/MochiKit.js/script
script type=text/javascript
connect(window, onload, function(){
var myTable = TABLE({border:1}, TBODY(null, TR(null, TD(null,
Hello), TD(null, World!;
appendChildNodes(myDiv, myTable);
});
/script
/head
body
div id=myDiv/div
/body
/html
This works just fine in IE 6, IE 7, and FF, no THEAD or TFOOT.
Jason Bunting
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.14.6/535 - Release Date: 11/15/2006
3:47 PM
--~--~-~--~~~---~--~~
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: setStyle() not in documentation?
On 10/30/06, Bob Ippolito [EMAIL PROTECTED] wrote: On 10/30/06, Jason Bunting [EMAIL PROTECTED] wrote: MochiKit advertises that one of the greatest things about it is the documentation and the accuracy thereof, as well as the fact that it is current with what is currently being developed. Because I have largely found this to be true, I rely on it quite a bit and it has been a HUGE help I love to show it to people because of how well it has been done and how much it helps. It doesn't advertise that the documentation is 100% in sync with the trunk. It definitely is for all of the *release* versions. My bad... One thing I don't see is any info on something I found, quite accidentally: setStyle() It's exported, so it's public API. It should be documented, but it isn't. getStyle and setStyle appear to have come from scriptaculous-inspired code, and the documentation effort for that portion of the code is a work in progress. The last question I have around this is whether or not I can use getStyle()? There is a comment in the code that indicates it is temporary and I just want to know if that comment means it will be going away or . . . ? Thanks, Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.21/509 - Release Date: 10/31/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] OT: Finite State Machine
Please excuse the off-topic nature of this, but does anyone know of, or have experience implementing, a finite state machine with _javascript_? I want to tightly control a set of user interface interactions and thought this might be the best approach and just wondered if someone else has already done something similar or know of something that may help I Googled around a bit but didnt find anything much. 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.21/509 - Release Date: 10/31/2006
[mochikit] Re: OT: Finite State Machine
On 10/31/06, Bob Ippolito [EMAIL PROTECTED] wrote: Finite state machines don't really have much to do with the language you're implementing them in. It's just a concept. I understand that... You might find some inspiration from Python FSM implementations, but it's pretty trivial to write one and there's a lot of different and equally good ways to do it. It depends on the situation. I guess I was simply wondering if someone had created any sort of helper framework of sorts for doing it in JavaScript to save me some time - they have similar types of components for C#, for example, that facilitate their implementation; maybe I am smoking crack... Thanks Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.21/509 - Release Date: 10/31/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: OT: Finite State Machine
On 10/31/06, Bob Ippolito [EMAIL PROTECTED] wrote: On 10/31/06, Jason Bunting [EMAIL PROTECTED] wrote: On 10/31/06, Bob Ippolito [EMAIL PROTECTED] wrote: Finite state machines don't really have much to do with the language you're implementing them in. It's just a concept. I understand that... You might find some inspiration from Python FSM implementations, but it's pretty trivial to write one and there's a lot of different and equally good ways to do it. It depends on the situation. I guess I was simply wondering if someone had created any sort of helper framework of sorts for doing it in JavaScript to save me some time - they have similar types of components for C#, for example, that facilitate their implementation; maybe I am smoking crack... Probably smoking crack. FSMs are so trivial that using a framework for them in a dynamic language would be pretty silly. It makes sense in something like C# or Java where you have to do all of that delegate garbage because functions aren't first class. A popular meme these days is that patterns are just workarounds for limitations in the programming language. C# and Java have a lot of patterns. JavaScript (Python, Ruby, etc.) can of course do all of the same things, but you don't normally call one or two lines of code a pattern. Okay, thanks - I actually found someone that mentions a 'framework' that they developed for facilitating FSMs with JavaScript (http://www.zedshaw.com/projects/cookbooxul/), but I think I will just take a stab at it myself then. Gotta get back to my crack pipe now . . . ;) Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.21/509 - Release Date: 10/31/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Finished port of ThickBox 2.1
I dont know that many will find this useful, but I thought I would mention it nonetheless I recently ported ThickBox 2.1 (http://codylindley.com/_javascript_/257/thickbox-one-box-to-rule-them-all) over to MochiKit (it was built on jQuery). Download it from here: http://www.sapientdevelopment.com/downloads/Mochikit/MochiKitThickBox.zip Short, useless blog post about it here: http://jasonbunting.com/blahg/PermaLink,guid,297d24b0-f5e8-47d1-82e2-1804133fc6bf.aspx If anyone improves it, I would love to have the changes. 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.17/505 - Release Date: 10/27/2006
[mochikit] Re: .Cookie or .Storage?
-Original Message- From: Beau Hartshorne Sent: Monday, August 28, 2006 10:58 AM To: MochiKit Subject: [mochikit] .Cookie or .Storage? I'd like to add a nice Cookie interface to MochiKit. Working with them manually sucks, but they're important for Ajax applications. Should we make it a submodule of some kind of Storage component that may or may not grow other persistence options? For what it is worth, I like the idea of abstracting storage and making it a submodule... Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.6/428 - Release Date: 8/25/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: beginners guide, for intepreter ajax
And I can only get clear() to work. I try a simple javascript command: writeIn(hello) as in the video demo, and I get an error writeIn is not defined... What am I doing wrong? It is *not* writeIn(), it is writeln(), and it works just fine. Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Next stable release?
To quote, in part, from the MochiKit site, in response to the rhetorical question, Which version should I get? : We recommend that you use the development version (and join the MochiKit mailing list!) when developing your applications. Once you're ready to deploy, it's usually time to switch over to the release version of MochiKit, so that your environment is easy to reproduce. We'll be releasing new versions of MochiKit on a regular basis, as we update the production version of our applications regularly! At my place of employment, we have been using the development version for the last 2-3 months and will be deploying our intranet app in September the fact that we are using this version has been okay for development, but some of our people are nervous about not seeing a stable version 1.4 of MK before we go live. Any idea on when this might happen? I just want to make people feel better about this. Thanks, Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006
[mochikit] Re: Is anyone working on autocomplete for MochiKit?
-Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of ChrisH Sent: Thursday, August 03, 2006 7:12 PM To: MochiKit Subject: [mochikit] Re: Is anyone working on autocomplete for MochiKit? snip Is everyone else layering scriptaculous on top of mochi, or writing your own widgets? - Chris I have been working on some widgets, and was planning on releasing them somewhere for others to use/critique. I do agree that these types of things should be separate from MK as a whole, since that would get unmanageable and I think the beauty of MK is in its simplicity. :) Jason -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/406 - Release Date: 8/2/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Naming conventions
Looking through the MochiKit source code made me curious as to the naming conventions followed; what is the significance of functions with one leading underscore character, and those with two leading followed by two trailing? And then there is __unstable__wrapElement which is neither 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/390 - Release Date: 7/17/2006
[mochikit] Re: developing with / for internet explorer
-Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Zachery Bir Sent: Saturday, July 15, 2006 6:47 AM Subject: [mochikit] Re: developing with / for internet explorer Drop the alerts, and liberally log() your way through the app, then use MochiKit's logging bookmarklet. MochiKit.Logging - we're all tired of alert() Zac The only thing I find useful about using alerts over log() is that alert calls stop execution, and in these situations (where you are not 100% sure which line is failing in IE) sometimes it helps to stop execution, look down at the IE status bar and see if the error has shown up or not - if it has, the bad line of code was before the alert, otherwise it was after. This is tedious, but works well in those cases where you are banging your head against the wall over and over. Jason Bunting -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/389 - Release Date: 7/14/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Re: [ANN] Public Beta of MochiKit-enabled IDE
-Original Message- Dear MochiKit Users, We're a small startup that has created a development environment (IDE) specifically for developing Web applications using HTML, CSS, and most importantly, JavaScript. We're really exicted to make this first public release available to the MochiKit community. snip Hmm, looks good, though the last thing I want to have open on my system is yet another tool - you guys thinking of offering any integration with Visual Studio? :P I will play around with it though! Jason Bunting -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.10/386 - Release Date: 7/12/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[mochikit] Problem with FF seeing all nodes in document...
I wrote the following function:
function
getAllByNodeAttribute(attribute, value) {
var elements = [];
MochiKit.Base.nodeWalk(MochiKit.DOM._document,
function (elem) {
if(getNodeAttribute(elem,
attribute) != null
getNodeAttribute(elem, attribute).toUpperCase() ==
value.toUpperCase()) {
elements.push(elem);
}
return elem.childNodes;
});
return elements;
}
I then have the following in my HTML:
mkw:IntegerTextbox id=foo1
cssStyle=font-size:16px; minValue=0 maxValue=500 /
When the page loads, I call the following code:
var allIntegerTextboxes =
getAllByNodeAttribute(tagName,
mkw:IntegerTextbox);
When this runs in IE 6, the array allIntegerTextboxes contains
the one node, just as I expect. However, in FireFox, there is nothing. I have
tried calling that function with a first parameter of nodeName
and localName but the result is the same.
Now, if I grab that element by the id (foo1) and iterate
over all of the keys and values of that node, the value of the tagName
attribute (as well as the other two I mentioned) shows the value I expect. Am I
missing something obvious (or not so obvious)?
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 -~--~~~~--~~--~--~---
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: 7/7/2006
[mochikit] Readonly textbox not readonly in IE
I have the following:
var textbox = INPUT({type:text, id:MyTextboxId, autocomplete:off, readonly:readonly});
In FF, I get exactly what I expect, but in IE 6, the
textbox is not readonly. Anyone happen to know why? If I call toHTML(textbox)
immediately afterwards, the results look like the following:
In IE:
input CHECKED=false accept=
align= alt= autocomplete=off
border= cache=null dynsrc=""
height=0 hspace=0 id=MyTextboxId
indeterminate=false loop=1 lowsrc=""
maxLength=2147483647 name=
readOnly=false readonly=readonly size=20
src="" start=fileopen type=text useMap=""
value= vrml="" vspace=0 width=0/
In FF:
input
autocomplete=off id=ADDL1_Input
readonly=readonly style=border: medium none ; margin: 0px;
padding: 0px; height: 16px; type=text/
This is driving me crazy I am hoping there is an
easy remedy
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 -~--~~~~--~~--~--~---
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
[mochikit] Re: Readonly textbox not readonly in IE
On Jul 5, 2006, Bob Ippolito wrote:
On Jul 5, 2006, at 11:19 AM, Jason Bunting wrote:
var textbox = INPUT({type:text,
id:MyTextboxId,autocomplete:off, readonly:readonly});
In FF, I get exactly what I expect, but in IE 6, the textbox is not
readonly. Anyone happen to know why? If I call toHTML(textbox)
immediately afterwards, the results look like the following:
Don't have Windows up and running right now, but I'd try
readonly:true
Well, I tried that as well and no love. Here is the funny thing: if I take
the exact HTML that the toHTML() call produces, past it into the page as
static HTML, it works just fine! So, this seems to be a problem with IE not
wanting to appropriately handle the dynamically-created textbox. In my
frustration, I even tried disabling the textbox and then re-enabling it in
the hopes that it would cause IE to take another look at things (I was
desperate and since IE is strange anyway, I thought it might just work!).
I will let you know if I figure anything else out
Thanks
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Re: Readonly textbox not readonly in IE
On Jul 5, 2006, Bob Ippolito wrote:
On Jul 5, 2006, at 11:19 AM,
Jason Bunting wrote:
var textbox =
INPUT({type:text,
id:MyTextboxId,autocomplete:off,
readonly:readonly});
In FF, I get exactly what
I expect, but in IE 6, the textbox is not
readonly. Anyone happen to
know why? If I call toHTML(textbox)
immediately afterwards,
the results look like the following:
Don't have Windows up and
running right now, but I'd try
readonly:true
Okay, at least I found a workaround for now if I add textbox.readOnly
= true; on the line
following the declaration of textbox, it works
just fine. Help me live!
Jason
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
[mochikit] Re: Readonly textbox not readonly in IE
On Jul 5, 2006, Bob Ippolito wrote:
On Jul 5, 2006, at 11:42 AM, Jason Bunting wrote:
On Jul 5, 2006, Bob Ippolito wrote:
On Jul 5, 2006, at 11:19 AM, Jason Bunting wrote:
var textbox = INPUT({type:text,
id:MyTextboxId,autocomplete:off, readonly:readonly});
In FF, I get exactly what I expect, but in IE 6, the textbox is
not
readonly. Anyone happen to know why? If I call toHTML(textbox)
immediately afterwards, the results look like the following:
Don't have Windows up and running right now, but I'd try
readonly:true
Okay, at least I found a workaround for now if I add
textbox.readOnly = true; on the line following the declaration of
textbox, it works just fine. Help me live!
Try putting this in your script somewhere and see if that helps. It
should have the same effect globally.
if (!MochiKit.DOM.attributeArray.compliant) {
MochiKit.DOM.attributeArray.renames.readonly = readOnly;
}
That worked - thanks! I am using the latest code; will this fix be in the
dev version soon?
Jason
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Question on key()
I am still trying to wrap my head around how things work in MochiKit, and after spending 20 minutes banging my head against the wall, humbly seek some assistance. I want to check all keys pressed, so I attach to that event like this: connect(window.document, onkeyup, HandleOnKeyUp); Now, in HandleOnKeyUp() I want to check for a certain key combinations I see in the docs that key() is supposed to give me what I want, but it is a method on an event object. Where do I get that? Having only had 8 hours of sleep in the last 2 days probably isnt helping me, but this seems like it should be easy. 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.7/379 - Release Date: 6/29/2006
[mochikit] Re: escapeHTML not working as stated
Where is a good place to learn about
closures?
From:
mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Bob Ippolito
Sent: Monday, June 26, 2006 1:35
PM
To: Sean De La Torre
Cc: MochiKit
Subject: [mochikit] Re: escapeHTML
not working as stated
Yeah, don't do that. That's totally wrong anyway. _javascript_ code *is
not* HTML! You need a function that escapes _javascript_ code.. or better yet,
just create a closure.
-bob
On Jun 26, 2006, at 12:32 PM, Sean De La Torre wrote:
It's not a markup issue;
rather, it's an issue when creating function inputs from data retrieved from
the server. For example:
// the current variable is an array.
current[current.length] = A({'href': '#',
'id': 'help_desk_delete_' + item.id,
'onclick':confirmDeleteHelpDesk(' + item.name
+ ',' + item.id + '); return
false;}, Delete);
In the code snippet above, if item.name
contains an apostrophe, it creates an invalid JS snippet for the onclick
statement. It's probably safer to only use the id to retrive the user
text, but I'll take a look at that later.
Sean
On 6/26/06, Bob
Ippolito [EMAIL PROTECTED]
wrote:
On Jun 26, 2006, at 12:08 PM, [EMAIL PROTECTED]
wrote:
Only changing the docs is fine by me.I just noticed the
discrepancy
because I had a problem with an apostrophe and thought that escapeHTML
would take care of it for me.Of course, it is probably just as
easy
for me to replace it myself, but I was being lazy :)
In what scenario would you have a problem with an apostrophe though?
It's not used in any markup.
-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 -~--~~~~--~~--~--~---
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date: 6/26/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date: 6/26/2006
[mochikit] Re: why the interpreter demo can't use help()
FYI, I get the same thing as well in FF and IE on WinXP. From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Wei Litao Sent: Tuesday, June 20, 2006 3:33 AM To: Beau Hartshorne Cc: MochiKit Subject: [mochikit] Re: why the interpreter demo can't use help() I use firefox. I tested dev version and local version and the link from your mail. The result is the same: help(map) blocking on Deferred(2, unfired)... Then no document whould be shown no metter how long I am waitting for. BTW, I have tested in IE, in my IE the result is help(map) documentation for MochiKit.Base.map not found On 6/20/06, Beau Hartshorne [EMAIL PROTECTED] wrote: On 19-Jun-06, at 11:35 PM, wlt008 wrote: When I type the help command like help(map), nothing happened... Works for me: help(map) map(fn, lst[, ...]) What browser/platform are you on? Are you using the version at http://www.mochikit.com/examples/interpreter/index.html , or from a source snapshot? -- Sincerely, Wei Litao -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.0/368 - Release Date: 6/16/2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.0/368 - Release Date: 6/16/2006
