[mochikit] Drag and Drop with constraints
Hi, I would like to use drag and drop functionality in one of the apps I am building. I was wondering if there is a way to set some constraints on the element being dragged; like for example I would like to drag the element in a rectangular region on the screen or inside a region under a div element. Reference: YUI has these methods for their DD element setXConstraint, setYConstraint example: http://developer.yahoo.com/yui/examples/dragdrop/grid.html?mode=dist Thanks, Saravana --~--~-~--~~~---~--~~ 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] NamedErrors are uncaught
Whenever I raise a NamedError, Firefox and IE tell me the error is
'uncaught'. But if I raise a standard javascript error, I don' have
this problem.
The standard error displays the message in a prettier manner and most
of the time I can have access to the error stack. I don't have theses
features with the NamedError.
Here is an little code snippet:
MyTest = function(param) {
bindMethods(this);
if (param == 1)
this._raise_a_named_error();
else
this._raise_a_standard_error();
};
MyTest.prototype = {
_raise_a_named_error: function() {
var err = new NamedError(TestException);
err.message = a named error;
throw err;
},
_raise_a_standard_error: function() {
throw new Error(a standard error);
}
};
// test code:
a1 = new MyTest();
a2 = new MyTest(1);
--~--~-~--~~~---~--~~
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] Async status success return codes question
I have been working with Async to build an inhouse web app, we have
ended up using the return codes to implement some interesting
behaviour in our clients.
MochiKit is just one of the clients that uses the web service and some
of our other processes (robots essentially) look for return codes to
act upon. One of these codes is 202 - Accepted. We use this in
response to requests that fire off long running processes in the
server. The server responds with a 202 saying that it is now running
the process and includes a location header to indicate where the
client should go to get updates on the current status of the process.
By default MochiKit doesn't treat a 202 as a success.
I have read the other messages on the list about this but there didn't
seem to be a consensus of opinion on why the current codes are
considered successes but others aren't.
I know that I could add an errback that redirects requests with 202 to
the success callback but it seems like a hack. I have changed the
following in my version of MochiKit;
From:
// 200 is OK, 201 is CREATED, 204 is NO CONTENT
// 304 is NOT MODIFIED, 1223 is apparently a bug in IE
if (status == 200 || status == 201 || status == 204 ||
status == 304 || status == 1223) {
d.callback(this);
To:
// Anything in the 200 range is a success.
// 304 is NOT MODIFIED, 1223 is apparently a bug in IE
if (((199 status) (status 300)) ||
(status == 304) ||
(status == 1223)) //..IE - sigh..
{
d.callback(this);
}
This new code looks like it is treating non-existent codes as
successes (for example 242 would be treated as a success), however the
RFC says that anything in that range is a success (well from my
reading anyway*) so I don't think that MochiKit should be putting its
own definition of what a success is on top of what the RFC says.
Any thoughts by anyone? Any chance MochiKit will change to work like
this?
Regards, Simon Cusack.
* The relevant bit of the RFC http://www.faqs.org/rfcs/rfc2616.html
is
10.2 Successful 2xx
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have been working with Async to build an inhouse web app, we have
ended up using the return codes to implement some interesting
behaviour in our clients.
MochiKit is just one of the clients that uses the web service and some
of our other processes (robots essentially) look for return codes to
act upon. One of these codes is 202 - Accepted. We use this in
response to requests that fire off long running processes in the
server. The server responds with a 202 saying that it is now running
the process and includes a location header to indicate where the
client should go to get updates on the current status of the process.
By default MochiKit doesn't treat a 202 as a success.
MochiKit is written mostly with practical considerations in mind, and
it only knows how to handle the specific success codes that it deals
with (the ones that you actually run into in the wild). It's easy to
make it do what you want though... something like this:
function http_2xx_ok(err) {
if (err instanceof XMLHttpRequestError err.number = 200
err.number 300) {
return err.req;
}
throw err;
}
var d = doXHR(...).addErrback(http_2xx_ok).addCallback(...);
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote: with (the ones that you actually run into in the wild). It's easy to Given the increasing popularity of REST, seems pretty likely you'll start running into a wider range of response codes in the wild. It's kind of disturbing to learn it's that noncompliant; we haven't settled on a library yet, but Mochikit was the front-runner for me. Now I'm back to I dunno, let's put all the names in a hat and pick one, since Wirebird makes use of pretty much the full range of HTTP responses. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
