Agreed. Nowadays I'm also in maintenance-only-mode with respect to
MochiKit. Meaning that I'll only address critical bugs or merge
well-documented tested patches. The MochiKit.Text module and version
1.5 won't progress further unless someone else steps up to do the
work.
That said, I'm still
that I might do if I
were doing this kind of localization. We've only done en and zh at
Mochi, so haven't needed anything outside of the system format.
On Mon, Jan 10, 2011 at 6:38 PM, Per Cederberg cederb...@gmail.com wrote:
Since I found the MochiKit.Format.formatLocale() function too
Since I found the MochiKit.Format.formatLocale() function too limited,
I hacked up a new MochiKit.I18n module:
https://github.com/cederberg/mochikit/blob/i18n/MochiKit/I18n.js
It is backwards compatible and adds locales for most languages on
earth (data derived from Wikipedia and Google
Being tired of all the idiosyncrasies of the typeof() operator, I
tried to make something better:
function typeName(value) {
if (typeof(value) !== object !(value instanceof RegExp)) {
return typeof(value);
} else if (value == null) {
return null;
}
Thanks for your input to the project, but I don't think we can
consider this a bug. Referring to objects that do not yet exist is an
error in almost any programming language, so it is to be expected. The
MochiKit docs do not explicitly make it clear that the id lookup is
immediate, but they
Thanks for your feedback!
I've updated the license text in the MochiKit repository with your patch:
http://github.com/mochi/mochikit/commit/60ac9815cb6a4d63a90936777ea7dc836caf7e94
We'll use the updated license for the 1.5 release (whenever that'll
be), but there are no current plans for
Being tired of all the idiosyncrasies of the typeof() operator, I
tried to make something better:
function typeName(value) {
if (typeof(value) !== object !(value instanceof RegExp)) {
return typeof(value);
} else if (value == null) {
return null;
While writing some MochiKit tests, I stumbled upon the following:
# compare(, [])
== 0
# == []
== true
Seems like the JavaScript type coercion is used inside compare():
compare: function (a, b) {
if (a == b) {
return 0;
}
...
But perhaps that was
Does anyone (Bob?) know why the MochiKit source code has these types
of comments for most exported functions:
/** @id MochiKit.Signal.connect */
Cheers,
/Per
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to
The download customization is now working. You can reach it here (also
linked from the new web site):
http://mochi.github.com/mochikit/packed/MochiKit/customize.html
Regarding tickets, if you are a stakeholder, please look through the
list and re-submit the ones you still think applies in the
When svn.mochikit.com is back up you can easily create your own
packaged version without any of the DOM packages. Don't know if any of
the magic initialization code in MochiKit uses the navigator, window
or document objects, but I guess they should detect if they are
missing. Otherwise we have a
No, there is no timeline. I planned a 1.4.3 bugfix release, but
haven't noted any particular interest for it. Seems most people (like
me) just use the svn trunk version right now.
On the topic of version 1.5, it seems work on it has mostly paused.
Some additions are included, but my own time for
Thanks for the patches, Niek! They've now been applied to svn trunk.
Cheers,
/Per
On Fri, Feb 19, 2010 at 09:32, Niek Kouwenberg
niek.kouwenb...@gmail.com wrote:
Okay,
Attached you'll find 361.patch for bug #361.
I also added a patch for bug #246, which was fairly simple.
On Thu, Feb 18,
I think the proper type check would be better written as o instanceof Array.
Also, previously we've been very cautious with breaking backwards
compatibility. The existing code supports JSON-serialization of
array-like structures, something that wouldn't be supported by the new
code. Perhaps we
Don't want to send stop-energy around, but is it really worthwhile to
pack MochiKit like that? I mean, the full MochiKit.js is only 197,5 kB
uncompressed. And the customizer we already have lets you pick quite
freely on the module level.
Have you double-checked what type of performance increases
I just tried to modify MochiKit.Base.evalJSON() to use the new
JSON.parse() function when available. This would give us the following
advantages:
1. Speed (but, well... eval() is probably fast enough already)
2. Security
Unfortunately we would also get a nasty regression issue due to the
Generally, I think some of these optimizations make sense. Like using
=== instead of == in code like this:
typeof(x) === string
But I think the optimizations where variables are moved outside code
blocks and where array lengths are stored to variables should be used
with extreme caution.
In ticket #352 the realISO parameter in the
MochiKit.DateTime.toISOTime() function is discussed:
http://trac.mochikit.com/ticket/352
It was introduced by Bob in r377 (some 4 years ago), but never added
to the documentation or the official API:
http://trac.mochikit.com/changeset/377
Is it
Mendaparamendapara.a...@gmail.com wrote:
Even better...
if (this.chain.length == 0 this._finalizer) {
this._finalized = this._finalizer(res);
}
This will allow us to finalize the deferred based on some
conditions...
- Amit
On Feb 11, 12:52 am, Per Cederberg cederb...@gmail.com wrote:
You mean like
The reassignment is for backwards compability if I understand it correctly:
if (typeof(decodeURIComponent) != undefined) {
decode = decodeURIComponent;
} else {
decode = unescape;
}
From the JavaScript 1.5 guide at Mozilla:
The escape and
This is the type of stuff one would rather not add to work-arounds in
the JavaScript code. Don't understand why Opera can't add stacktraces
as separate properties to their exception objects instead? Or is it
just that they've modified the toString() implementation?
Cheers,
/Per
On Sat, Jul 11,
Mostly, these issues are caused by lingering references to the removed
DOM nodes (lookup tables, etc). In this case, since you use MochiKit,
you might want to look at the MochKit.Signal.disconnectAll().
It might also be helpful for some older browsers to tear down the DOM tree.
Here's a helper
I think the current location is quite fine, if not in the MochiKit
repo itself. Should perhaps add a link from the Wiki pages, though...
If you'd like to contribute new widgets, I'd love to include them!
Just fork the git repo and send me a pull request when done.
Regarding other widget
Hi David,
Nice to see someone using my widgets for MochiKit!
The Git repository has been out of date for a while, since nobody has
been asking for updates. But now that you've patched the code, I've
also updated my copies to the latest version. Will try to merge in
your stuff as well.
It was
In order to break this down a bit, could you try the page with just
the MochiKit.Base module? Use the download customizer to create a
minimized version with the modules you wish to try.
http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/customize.html
We need to know more details about
I'd prefer a non-incompatible fix for this. One obvious improvement
would be to add a dict() function:
http://github.com/cederberg/mochikit-patches/blob/1e0dd2fcc3c80e1fe78f87d9ca7d9ba16b9eee09/MochiKit/Base.js#L71
But for forms, some values might be repeated so that wouldn't solve it
all.
On Thu, Feb 26, 2009 at 2:35 AM, Giulio Cesare Solaroli
giulio.ces...@gmail.com wrote:
Hello Per,
On Wed, Feb 25, 2009 at 7:54 PM, Per Cederberg cederb...@gmail.com wrote:
Interesting that you're using SimpleTest! It is on my not-so-secret
agenda for 1.5 to merge that into MochiKit.Test
Try using Firebug and step though your code. From Firebug you can
inspect the DOM properties of individual elements as well as modify
the CSS properties.
Cheers,
/Per
On Tue, Feb 24, 2009 at 4:16 AM, David Ximenes davi...@yahoo.com.br wrote:
hi,
(sorry, my english children´s, i´m from
I think this is a good idea. I needed something similar too, so I
ended up writing an ugly hack that worked most of the time...
d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
It adds new callback once the first deferred result drops in,
hopefully after all the other
scroll the whole window. I'd like to scroll only the left part.
B.
On 29.1.2009, at 23:13, Per Cederberg wrote:
Don't understand your question I'm afraid... Are you looking for
style=overflow: auto;? Or MochiKit.Selector.$$(div.left)???
Cheers,
/Per
On Thu, Jan 29, 2009 at 10:23 PM
var elem = $$(div.left a.link3);
/Per
On Fri, Jan 30, 2009 at 1:57 PM, Boštjan Jerko ml...@japina.eu wrote:
On 30.1.2009, at 11:15, Per Cederberg wrote:
Ok, this isn't really MochiKit-related, but define your CSS class as
follows:
.left {
overflow-y: auto;
height: 100
Don't understand your question I'm afraid... Are you looking for
style=overflow: auto;? Or MochiKit.Selector.$$(div.left)???
Cheers,
/Per
On Thu, Jan 29, 2009 at 10:23 PM, Boštjan Jerko ml...@japina.eu wrote:
Hello!
I'd like to link a function (to scroll the data) to a div I have.
The
On Tue, Dec 16, 2008 at 3:47 PM, Eoghan eoghanomur...@gmail.com wrote:
2. Modify the lookup by id convention to lookup by selector + map:
connect('#my-ul li', 'onclick', func);
Yes, changing these lookups would break the current API. But it
wouldn't be impossible to create a migration path
();
}
);
/script
On Dec 7, 11:10 pm, Per Cederberg cederb...@gmail.com wrote:
If you could provide more details on exactly what is breaking it would
be easier to help. Perhaps a minimal HTML file exposing the issue? If
you can find any error or debugging
Thanks for the clarification, Bob!
Regarding the functions in questions I think other names might be in
place, to avoid misleading interpretations. What we're really doing
here is attempting to patch the poor JavaScript syntax and/or standard
library for function calls (i.e. call, apply,
On Wed, Dec 17, 2008 at 5:11 PM, Arnar Birgisson arna...@gmail.com wrote:
One comment about startsWith, endsWith, contains etc.. currently they
take first the haystack and then the needle (I'm talking about
parameter order). Perhaps switching this could benefit the usecase
where this is used
Hi everyone,
I've just finished committing one of my planned additions to MochiKit
1.5 -- a new MochiKit.Text module:
http://www.mochikit.com/doc/html/MochiKit/Text.html
It basically provides some of the text formatting stuff discussed here
on the list previously. With some random string
The names curry and uncurry were a bit confusing to me, so it took
me a while to understand these two functions...
http://en.wikipedia.org/wiki/Currying
To me (and probably other non-Haskell users) the names imply the same
thing as bind or partial. It's a confusing world... :-(
In
Naturally I meant:
getElementPosition(descendant, parent);
... and not the other way around.
/Per
On Mon, Dec 15, 2008 at 12:34 PM, Per Cederberg cederb...@gmail.com wrote:
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two
On Mon, Dec 15, 2008 at 1:11 PM, Per Cederberg cederb...@gmail.com wrote:
Ah, yes... You are probably right. Thanks for the analysis!
It only makes sense for getElement() to return a Node or
null/undefined. Other return values are probably just a side-effect
for the fast-path return for DOM nodes
Due to a new set of weird rounding errors in JavaScript floating-point
numbers, I opted to fully replace the MochiKit.Format.truncToFixed and
roundToFixed functions with new implementations. This basically
affects all of the other MochiKit.Format functions as well. The new
code pass all the tests
, Amit Mendapara
mendapara.a...@gmail.com wrote:
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug
think,
var elem = MochiKit.DOM.getElement({});
should return `null` or `undefined` but it returns the argument in
this case. The check
if (!elem || elem == d) {
return undefined;
}
in getStyle fails due to this...
- Amit
On Dec 15, 4:34 pm, Per Cederberg cederb...@gmail.com wrote
I think it is an interesting idea to be able to bind any argument
position. Think I mentioned it earlier in the 1.5 API discussion that
we now have quite a few variants of bind-like functions -- bind,
bindLate, bindMethods, forwardCall, partial, method, methodCaller...
Too many for my taste, so
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /*
To me it seems both version should work equally well. Each function
scope created should be linked together, causing the my_var variable
lookup to be found in the outer function when not defined in the local
function scope. Unless I've misunderstood something about variable
scoping in JavaScript.
Store your old effect in a global variable or similar:
var currentEffect = null;
Then finish off any old effect before starting new ones:
if (currentEffect) {
currentEffect.finish();
}
currentEffect = slideDown(...);
Cheers,
/Per
On Mon, Dec 1, 2008 at 1:49 PM, Ranjan [EMAIL PROTECTED]
Thanks! It has been committed in r1489:
http://trac.mochikit.com/changeset/1489
Cheers,
/Per
On Mon, Dec 1, 2008 at 2:52 PM, Eoghan [EMAIL PROTECTED] wrote:
Below is a patch for findChildElements to make it look up the element
if it is passed by id rather than DOM reference:
Index:
Just completed the removal of built-in JSAN and Dojo toolkit support
(r1482), which was next in the series of minor 1.5 changes. Also made
some changes to the module headers to shave of a few kb of loading
time (r1483). Next up will be the function exports.
A new wiki page attempts to document
Actually, I don't think it is possible (from reading only the
documentation). The log filtering is only applied to listeners. But
even they cannot affect what is being sent to the native console.
I think you'd have to assign some of the log* methods to
MochiKit.Base.noop in order to silence
MochiKit 1.4.2 has now been released and is available on the web site:
http://mochikit.com/download.html
http://svn.mochikit.com/mochikit/tags/MochiKit-1.4.2/packed/MochiKit/customize.html
This version contains the correction of a few issues found since the
last release:
* More fixes in
Arnar, thanks for the update! I'm in no hurry myself, having plenty of
other things to focus on. :-)
Hope you have a nice trip!
Cheers,
/Per
On Thu, Nov 20, 2008 at 11:55 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hi Per,
On Tue, Nov 18, 2008 at 23:04, Per Cederberg [EMAIL PROTECTED
elements, such as onshow, onhide, etc. As a side-note, this is the
first 1.5-only change to MochiKit so far.
Cheers,
/Per
On Wed, Oct 29, 2008 at 3:33 PM, Per Cederberg [EMAIL PROTECTED] wrote:
Actually, I think the whole API for the signal() function needs to be
sanity-checked. It works rather
Thanks for a great bug report and patch, David!
It has been applied in r1466 and will also show up in 1.4.2 (eventually).
Cheers,
/Per
On Tue, Nov 18, 2008 at 12:19 AM, David Barnett [EMAIL PROTECTED] wrote:
Hi guys,
I found a somewhat obscure bug in getViewportDimensions that appears in
After some experimenting and tinkering, I've finally linked the
MochiKit Customizer from the download web page:
http://www.mochikit.com/download.html
It is available in two flavors, both for 1.4.2 (upcoming) and svn
trunk. And is also included in the full zipped install file (in the
packed
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
I don't follow the Sizzle development very closely, but I seem to
remember having seem some check-ins dealing with similar issues.
Perhaps the time is right now to just go ahead and merge the new
selector branch into the 1.5 trunk? With the appropriate updates from
the base Sizzle implementation
When you call setInterval and setTimeout you should provide functions.
In your first example you perform a function call to setTimeout and
then send the result to setTimeout. That leads to an infinite loop.
Instead, do this:
var func = function() { check(tab); };
setTimeout(func, 1000);
???
Cheers,
/Per
On Thu, Nov 13, 2008 at 4:08 AM, Reka Sandaruwan
[EMAIL PROTECTED] wrote:
how to create action button on tree node
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to
We'd like to know:
1. Which web browser? Which OS?
2. Have you got an example to show this? Where is it? Please provide a URL.
Cheers,
/Per
On Mon, Nov 10, 2008 at 10:43 PM, scipio [EMAIL PROTECTED] wrote:
I have a div with a top margin of 35px laid out using fixed
positioning, and when
On Fri, Nov 7, 2008 at 11:05 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
As I understood the example, the objects being modified take care of
calling signal(). E.g. a hash table that fires a signal when objects
are added, removed and even when there's a collision. Guilio Cesare
would like to
and details on the licence here:
http://www.clipperz.com/learn_more/reviewing_the_code
I will post back as soon as I managed to commit the NotificationCenter
into the code.google SVN repository.
Sorry for the trouble.
Best regards,
Giulio Cesare
On 11/21/07, Per Cederberg [EMAIL
checked to be sure, it fails with r1464)
thanks for the fast fix
Per Cederberg wrote:
Could you try again with r1465?
Thanks for the excellent bug report, btw.
Cheers,
/Per
--
Brad Clements,[EMAIL PROTECTED](315)268-1000
http://www.murkworks.com
Could you try again with r1465?
Thanks for the excellent bug report, btw.
Cheers,
/Per
On Mon, Nov 3, 2008 at 6:05 PM, bkc [EMAIL PROTECTED] wrote:
I have a production site that is using this svn url:
http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/MochiKit.js via
an external
MochiKit 1.4.1 has now been released and is available on the web site:
http://mochikit.com/download.html
This version contains the correction of a few issues found since the
original 1.4 release:
* Added export of deprecated MochiKit.DOM.computedStyle function (#324).
* Fixed issue
There is a new (hopefully working) version of the download page available now:
http://mochikit.com/pack.html
It only provides customized downloads from svn trunk at the moment.
And due to the default packed version not including all modules, some
modules are not available...
If you have
On Fri, Oct 31, 2008 at 1:15 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
To draw from Python again, both could be implemented with one function
called bool. This would convert any object to a boolean.
Nice idea!
How about a generic first function in Iter? Would be
first(someCheck,
Ok, thanks! I was a bit sloppy in my first implementation, but in
r1453 I added all the display styles below. Some of them might break
in IE6 and so, but it is still better than being broken all the time
(as you pointed out).
Thanks for reviewing the code!
Cheers,
/Per
On Fri, Oct 31, 2008 at
be a good edge case example to add to the docs under
Synopsis - Signal for DOM events:
Eoghan
On Oct 29, 12:04 pm, Per Cederberg [EMAIL PROTECTED] wrote:
The documentation isn't very good at this point. But you probably want
to mock the browser event object:
var fakeEvent = {};
signal('my
It has been discussed previously here on the list, but since 1.4
wasn't released then I don't think anybody bothered to do anything.
With version 1.4 finally out there, perhaps the time for action is
now?
Feel free to try to contact Google about this. Personally I wouldn't
bother, since I've
On Mon, Oct 27, 2008 at 11:34 AM, SanderElias [EMAIL PROTECTED] wrote:
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
These are available as strip(), lstrip() and rstrip() in
I just ran into a bug that I can't resolve. At least I'm out of ideas right now:
http://trac.mochikit.com/ticket/325#comment:2
The problem is when using getElementDimensions() on elements having
display: none set in the CSS class. Or in a parent element. Is there
a work-around for this? Or
is set on the element itself. But not on in the CSS
class.
So, I think we're still stuck... :-(
Cheers,
/Per
On Mon, Oct 27, 2008 at 12:44 PM, Andreas Marienborg
[EMAIL PROTECTED] wrote:
On Oct 27, 2008, at 12:30 PM, Per Cederberg wrote:
I just ran into a bug that I can't resolve. At least
+). But there may be
a trick I'm not aware of that explains this particuliar choice.
2008/10/27 Per Cederberg [EMAIL PROTECTED]:
Thanks for the suggestion, but that sort of code is already in
getElementDimensions I think:
if (disp == 'none' || disp == '' || typeof(disp) == 'undefined
This has been discussed earlier and I closed the ticket myself:
http://trac.mochikit.com/ticket/299
But perhaps it would be worth changing the documented API for this?
What do other people think?
Cheers,
/Per
On Mon, Oct 27, 2008 at 6:27 PM, Giulio Cesare Solaroli
[EMAIL PROTECTED]
Actually, I think the documentation for roundElement and roundClass
should be clearer regarding these limitations. From reading the docs,
it is not obvious that only block elements are accepted (my guess).
And what do these methods really change in the DOM tree? A simple
explanation might help
to reluctantly inaugurate a
brand new svn branch for 1.4. Please add any regression fixes to 1.4
there (and drop a mail on the list).
Thanks,
/Per
On Fri, Oct 24, 2008 at 8:51 AM, Per Cederberg [EMAIL PROTECTED] wrote:
Yes, I noted the same thing yesterday. Seems to be an issue
(on Linux). Please make sure that it's packaged properly
with correct access permissions.
- Amit Mendapara
On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote:
MochiKit 1.4 has now been released and is available on the web site:
http://mochikit.com/download.html
The full change
My guess would be that the speed difference stems from the Sizzle
strategy of searching inside-out from the expression. I.e. using the
last part of the query first, and then filtering that set using the
previous parts. Perhaps other libraries search outside-in?
In the case of ul .tocline2 the
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,
Of course, FF 3.1 includes querySelectorAll:
http://ejohn.org/blog/queryselectorall-in-firefox-31/
And in fact, there is a slight bug in Sizzle here, causing it to not
use that version when not sending in an explicit 2:nd argument:
Sizzle(..., document)
The problem is here:
if (
Ok, since r1433 MochiKit.DOM.isParent is no more.
/Per
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group,
Attempting two answers in one below...
On Sat, Oct 18, 2008 at 12:23 AM, Jason Bunting
[EMAIL PROTECTED] wrote:
Who is Noone? :P
Sigh... The endless joys we bring you native English speakers... ;-)
On Sat, Oct 18, 2008 at 5:54 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
Hm, if I read
Hi everyone,
This is just to say that I'm still planning to do the MochiKit 1.4
release on the 21:st of October. All outstanding bugs remain fixed and
I've heard of no test breakage. Please let me know if you find any
last-minute-issues.
Cheers
/Per
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
On Wed, Oct 15, 2008 at 1:01 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Done. Yup, the number of nodes is not correct (or at least as correct
as th other frameworks). Performance takes a minor hit, mainly because
it is so bad to begin with :)
Ah, you mean now correct... :-)
Disturbing that
:21 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hi Per,
On Wed, Oct 15, 2008 at 10:15, Per Cederberg [EMAIL PROTECTED] wrote:
On Wed, Oct 8, 2008 at 9:28 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
div p
MK trunk returns 142 elements while others return 140 (both numbers
are reported
with MochiKit.Selector while testing
MochiKit.Query module. As `Per Cederberg` is preparing for 1.4
release, I think MochiKit.Selector should not be included in 1.4, but
let we get something really useful with Sizzle which is going to be
integrated in MochiKit (hopefully MochiKit 1.5)...
- Amit Mendapara
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara
[EMAIL PROTECTED] wrote:
Once, I filed a bug report on the trac (related to Sortables), but I
was unable to change/comment it later. That's why I never submitted
again.
Yes, this is very unfortunate. I used to have the same problem, so I
hear
:38, Per Cederberg [EMAIL PROTECTED] wrote:
The packed version of MochiKit still doesn't include the modules
DragAndDrop and Sortable. I found a previous discussion of that in
this thread:
http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
None
Google code seems fine by me. Especially if we get better access for
normal users.
The only issue I come to think of is that the mochikit.com web site
automatically updates from svn trunk. Don't know if it would be easy
to keep that link. Something which is pretty good to have from time to
time.
On Mon, Oct 13, 2008 at 2:24 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Minor usability pointer: When unselecting a module, instead of
unselecting everything that depends on it - highlight the relevant
part of uses XXX of those in some /error/ color.
I fooled around a bit with the visual
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.
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.
But sure, there is an inconsistency here. My suggestion would be to
just
The packed version of MochiKit still doesn't include the modules
DragAndDrop and Sortable. I found a previous discussion of that in
this thread:
http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
None of the two modules have been much modified lately,
Perhaps the problem is that you've already used bindMethods on the
Helper class before subclassing? That might break the inheritance
depending on how the code looks, since it reassigns the this object
pointer to another instance.
Also, you must use the new keyword, or it won't work:
While fixing some stuff in MochiKit.Logging, I happened to notice the
existance of a MochiKit.Test package... It seems pretty similar to the
SimpleTest.js file used for powering the normal test suite when run
inside a browser, but it seems to only be used when standalone testing
is performed
Ok. I added an enhancement ticket so that I won't forget about it:
http://trac.mochikit.com/ticket/320
Thanks for the info!
/Per
On Wed, Oct 8, 2008 at 4:20 PM, Leo Soto M. [EMAIL PROTECTED] wrote:
On Wed, Oct 8, 2008 at 9:46 AM, Per Cederberg [EMAIL PROTECTED] wrote:
While fixing some
On Wed, Oct 8, 2008 at 4:26 PM, troels knak-nielsen [EMAIL PROTECTED] wrote:
9.50 Alpha .. 8 failures in test_MochiKit-Style.html
not ok - initial x position: got 444, expected 400
not ok - initial y position: got 111, expected 100
not ok - updated x position: got 544, expected 500
The draft version of MochiKit.Format.format() and formatter()
functions are now ready for testing. They are not documented much,
except for my previous email in this thread. And the API shouldn't be
considered stable.
So I push the bits into my temporary patch repository instead:
1 - 100 of 173 matches
Mail list logo
