Firefox bug?
RobG
example, so I started by creating a simple drag object. It took a
little while to work out that the item being dragged is referenced by
this.selected, where 'this' is the DragManager instance.
That would have been avoided (well, maybe) if there was some
documentation that listed the properties of a dragManager. The drag
documentation seems more interested in the philosopy behind the
library rather than stuff that is helpful to users (i.e. programmers).
Peter, is it possible to create a documentation Wiki or some form of
auto-generated documentation from the code? Even if it was just basic
API properties, methods, expected arguments, etc. - it need not fully
document the internals.
--
Rob
RobG
Peter Michaux
On Wed, Sep 3, 2008 at 7:02 PM, RobG <rg...@iinet.net.au> wrote:
[snip]
> That would have been avoided (well, maybe) if there was some
> documentation that listed the properties of a dragManager. The drag
> documentation seems more interested in the philosopy behind the
> library rather than stuff that is helpful to users (i.e. programmers).
It is generous of you to refer to that as "documentation".
The reason the documentation is not written properly is I'm not sure
what to do about the drag-drop library. I don't really like how the
code is arranged aesthetically (the feature testing especially.) It
does work well and can be used to build very fast interfaces. I'm
going to need drag and drop for something new in the next few months
and I was putting this one part of the Fork 0.2 overhaul off until my
brain is fully engaged.
For the time being if you have any questions feel free to ask on this list.
> Peter, is it possible to create a documentation Wiki or some form of
> auto-generated documentation from the code? Even if it was just basic
> API properties, methods, expected arguments, etc. - it need not fully
> document the internals.
Yes, eventually there will be documentation in Fork included in the
source code and then extracted to HTML. I have had the system working
for xjs
The source code:
http://dev.michaux.ca/svn/xjs/trunk/Assert/lib/Assert.js
The resulting page:
http://xjs.michaux.ca/documentation/current/Assert.html
I am a big fan of documentation. I've used the
http://forkjavascript.org/ site many times myself (never can remember
how the cookies API works) so better documentation for the drag-drop
code will surface.
Right now I'm working on server-side JavaScript stuff with xpkg and
xjs 0.1.0 and that will be a big step forward for xjs itself and also
for the documentation of Fork 0.2.
------
Did you determine a decent feature test for the touch events interface?
Peter
RobG
On Sep 4, 12:24 pm, "Peter Michaux" <petermich...@gmail.com> wrote:
[...]
> Did you determine a decent feature test for the touch events interface?
so that a global supported event features list is created that can be
used to test if a particular feature can be used later.
I'm currently using it as follows (excuse wrapping, this is straight
from the code):
FORK.Event.supportedEvents = (function () {
var evt, eventFeatures, eventType;
var supportedEvents = [];
var allFeatures = {
// Draft events implemented in Mobile Safari (iPhone)
Safari : ['TouchEvent', 'GestureEvent'],
// Implemented in Gecko by Mozilla
Gecko : ['MessageEvent', 'MouseScrollEvents', 'PopupEvents',
'PopupBlockedEvents', 'XULCommandEvent', 'XULCommandEvents'],
SVG : ['SVGEvents', 'SVGEvent', 'SVGZoomEvents',
'SVGZoomEvent'],
// W3C 2.0 events
DOM2 : ['UIEvents', 'MouseEvents', 'MutationEvents',
'HTMLEvents'],
// W3C 3.0 events
DOM3 : ['UIEvent', 'MouseEvent', 'MutationEvent',
'MutationNameEvent', 'TextEvent', 'TextEvents',
'KeyboardEvent',
'KeyEvents', 'Event', 'Events']
};
if (document.createEvent) {
for (var features in allFeatures) {
eventFeatures = allFeatures[features];
for (var i=0, len=eventFeatures.length; i<len; i++) {
eventType = eventFeatures[i];
if (testEventType(eventType)) {
supportedEvents.push(features + ':' + eventType);
}
}
}
}
return supportedEvents.join(',');
/* Not happy using try..catch, an alternative
* is to use hasFeature(), but can that be trusted?
*/
function testEventType (eventType) {
try {
document.createEvent(eventType);
return true;
} catch (e) {
return false;
}
}
})();
To check if an event interface is supported:
FORK.Event.isSupportedEvent = (function () {
return function(eventType) {
var re = new RegExp(':' + eventType + '(,|$)');
return re.test(FORK.Event.supportedEvents);
}
})();
Usage:
if (FORK && FORK.Event &&
FORK.Event.isSupportedEvent('TouchEvent')) {
/* touch events supported */
}
My current thinking is to change it to properties of an object, the
string was just a cheap way of being able to see a list using split &
join. The caveat is that even though the events might be supported,
there might be no way for a user to actually fire them through the
interface.
The above is also useful for some code I've done that wraps
dispatchEvent, you can just do sendEvent(el, 'click') and it
dispatches a click event into the DOM with el as the target you don't
have to know that click belongs to MouseEvents or test if the
interface is supported.
Why do this? Because it should be easier with a touch interface to
simulate a couple of events rather than implementing a whole different
interface based on UA string.
--
Rob