[ng-dhtml] feedback and requirements from google

Tom Trenka ng-dhtml at dept-z.com
Sun Aug 8 21:56:48 CDT 2004


> The key points that were communicated where:
> 
> 	* the ability to prefix our namespace
> 		e.g., com.informatica.dojo = dojo;
> 	* XML handling
> 	* frame utilities (likely a comm layer implementation)
> 	* high degree of componentization (pick-and-choose for 
> smallest possible size for given task)
> 
> I think most of these were already on our roadmap, and the 
> ones that are new (the prefixability requirement) seem 
> reasonable and will force us into even better portability.
> 
> Thoughts? Reactions?

Seems to me that all of these things (including the prefixing) was already
on our list.  To wit:

1.  Prefixing
>From my understanding, we'd already discussed the ability to do this:

var dojo = org.dojotoolkit.dojo;

I really don't see any issues there at all.

2.  XML Handling
...I'll get back to this.

3.  Frame utilities
For what it's worth, I already have a pretty solid implementation of this
(not included with f(m) yet) that I've been using for at least 2 years now;
it's based on the standard IFRAME comm layer from Brent Ashley (is that
right, I can never remember), and it's pretty much just a namespaced version
of that, with a pool of up to 16 IFRAME elements available (usually I never
get past two, but I did that so that errors/page timeouts take a long time
to break the system).  It could stand for some improvement; two things I'd
like to see are setting up the onload callback in the parent window (as
opposed to having to set it up in the loaded page), and not having to have a
specific server component to understand the protocol.  As I said, it's over
2 years old...

Also for what it's worth, I think the frame approach for comm is a bad one;
there's nothing more annoying to me than hearing lots of clicks (the
standard windows "I just loaded a web page sound", for instance) and having
no idea why.  I much prefer the XMLHTTP approach...

4.  A high degree of componentization
I thought this was exactly what we were shooting for? :D

...back to XML Handling
I've wrestled with this question for quite some time, and in fact it's been
the main sticking point for me with f(m).  What I'd *like* to do is set up a
script-based XML engine that's not only as compliant as possible, but also
handle a variant on XMLHTTP as well (but *not* supporting Load and Save, my
opinion on that one is that it is a bad model to have an object be able to
load and save itself; that functionality is best relegated to a Manager
which would deal with multiple documents and fragments).  I began a bit of
that work for f(m) based on the REXML parser...I'd gotten about 2/3 of the
way through (including an Xpath implementation, that's about 3/4 of the way
done, just need to do the nitty-gritty of predicate parsing, just been too
lazy to write up the stack at this point), and for the most part it follows
the MS model, which is really not much different than the W3 model (with the
exception of .selectSingleNode and .selectNodes, which seem to be MUCH
easier to deal with than using the W3 Xpath evaluator mechanism).

My game plan was to look into putting together a Java applet that would
handle the same basic functionality as XMLHTTP does.  Frankly I'm a bit
disappointed with the Moz version of XMLHTTP, and don't have access to a Mac
at all (so I don't know if I'd be happy with the Safari version either).

Personally I have no problem requiring one of the three major browsers if
XMLHTTP is to be used; they're all pretty ubiqutous, and Web-fx's XmlExtras
have demonstrated that doing it cross-browser isn't too much of a
deal-killer.  But still, I wouldn't mind writing a script-based parser and
including it.

TRT




More information about the NG-DHTML mailing list