>> MTeF> I strongly disagree with this. Both about the documentation and the
MF> power
>> MTeF> :-)
>>
>> Oh really... :)
MF> Just tell me about something that you would like to implement as DW's
MF> extension and you can't due to the API's limitations
For one example, setting focus. Focus needs to be able to be set from
anywhere, to anywhere. This is especially problematic with dynamic
content in a floater as doc.write has, i assume unintended,
consequences in regards to focus.
Floaters themselves need all of the DOM events...onmouseover is a big
one. Onmouseover...floaters need to be able to be focused.
Onrightclick is another big missing one.
>> How exactly does an extremely small subset of DOM 1 that is
>> implemented unevenly across the different objects qualify as
>> powerful? To say nothing of DOM 2 or 3.
MF> See above, what part of DOM 2 or 3 do you need inside the API, and why?
doc.write being the only way to dynamically alter content is so 5
years ago, slow, and has obvious code maintenance problems. The world has
DOM 2 now. Fourth generation browsers are dead, and doc.write is lame.
>> How does the fact that all the menus are very nicely defined in XML
>> files, but no one has thought to distribute DTD's of any kind qualify
>> as well documented?
MF> Do you really feel like it's so hard to read without a DTD?
MF> Do you think HS's stuff is better documented?
A simple DTD says so much about an XML document...it's vastly
superior to the few paragraphs and examples given.
Homesite's built in objects and functions are documented clearly and named
logically. It also benefits from the fact that tons of preexisting
documentation exists for the WSH languages and COM objects.
>> How can DW's data connectivity compare in any regard to ADO for power?
MF> I never felt the need to connect to a datasource from a DW's extension, but,
MF> apart from C++, you can leverage Flash Remoting too
I can't remember who developed it, but I'm sure you have seen that
cool new DW data wizard that was recently released. It's
great...except DW's data limitations wont allow an editable
grid, just viewing. Even WebMatrix allows data editing, and it's
free.
>> DW allows only JS or C, HS allows any language built on WSH, meaning
>> VBS, JS, Kix, etc., and any language a COM object can be written in.
MF> There is a huge difference here, DW API are cross-platform.
I only use DW on one platform...I don't see why I have to be
limited. Would it be hard to allow Windows people to use WSH and allow
Mac people to use AppleScript?
>> Why the heck is DWFile so slow?
MF> How many files you need to process with it? I used it for up to 2-3.000
MF> files testing my site-wide extensions, it does the job, I never felt the
MF> need for anything faster (remember it's cross platform too)
Directory listings read from the HD directly every time instead of
using the Windows API's ability to cache directory listings.
>> I also can't speak to the C API, knowing very little C, but how many web
>> developers know C?
MF> I don't, but I was still able to do a few not too trivial things using DW's
MF> API
>> The only thing going for DW is the UI extensibility, which is awesome,
MF> And leaves HS in the dust here... :-)
MF> Try this for example:
MF> http://www.communitymx.com/content/article.cfm?cid=A1EDDF56F77EE7CA
A custom floater in Flash? Nice looking...still has all of Flash's UI
problems like lack of right-click, and scroll button though. I
want to extend my IDE because I want more usability out of my IDE, not
even more usability problems.
DW does trump HS with the ability to alter the UI, but just putting a
sticker on the side of the box doesn't make it so. It's has to fully
deliver that capability.
>> I can't help but feel that the whole DW
>> extensibility thing has not enough resources, meaning people working
>> on it, or it has too many, and not enough organization. Maybe it's
>> because it has to run on the Mac as well that is holding it back.
MF> I am not pretending DW's API is perfect, but I stand by my words saying that
MF> I strongly disagree with your statement about HS's extensibility being more
MF> powerful or better documented
>> I think Mozilla is the model of what DW extensibility model want's to be.
>> XUL/XBL/XPCOM kicks butt...or even HTML/DOM2/XML Events. Whatever the
>> solution is, DW needs it. It's really lagging.
MF> Well, actually DW predates Mozilla, the XML menus were based on the very
MF> early draft of XUL (back in 1999)
Four years...The extensibility team been on hiatus since then?
I know this stuff isn't trivial to implement, but it's what I expect
when I look over and see guys using WebMatrix and VS.Net. I never
claimed to be a reasonable guy either :)
--
jon
mailto:[EMAIL PROTECTED]
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
